Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2009/wiki2 16 rs

2009-10-15T01:30:28Z

Screenit: /* Glossary */

CSC/ECE 517 Fall 2009/wiki2 16 rs

SOA provides another view of providing functionality based upon services offered in terms of protocols and a specific API. Research and report on what patterns have been proposed and are utilized within this domain. How do they differ from traditional design patterns proposed by Eric Gamma, Richard Helm, Ralph Johnson, and John Vlissides? How are they similar?

----
=Introduction=

This article focuses on the design patterns which are proposed and utilized in the [http://en.wikipedia.org/wiki/Service_oriented_architecture Service Oriented Architecture]. As the SOA provides its services through the protocols and API, this article throws light on the design patterns that specifically provide services through protocols like [http://www.soapatterns.org/canonical_protocol.asp Canonical protocol], [http://www.soapatterns.org/dual_protocols.asp Dual protocols] and [http://www.soapatterns.org/protocol_bridging.asp Protocol Bridging]. In a broader perspective, other design patterns have been explained tersely. In addition to explanation of the SOA design patterns, this compares the SOA design patterns with the traditional design patterns proposed by the ‘Gang of Four’ (Eric Gamma, Richard Helm, Ralph Johnson, and John Vlissides) and comes up with the differences and similarities between them.

=Service Oriented Architecture-An Overview=

==SOA-Definition==

A [http://en.wikipedia.org/wiki/Service_oriented_architecture Service Oriented Architecture] is an architecture that provides collection of services. These services need to inter-operate with each other to provide the functionality. This architecture requires a loose coupling with operating systems and other technologies that form the basis of the application. The loose coupling between services is required because each interaction has to be independent of the other. The communication between services could be either simple data being passed or it could be either an activity coordinated between distinct entities or services. Some means of interoperability is required to provide the services in larger terms. Instead of defining the [http://en.wikipedia.org/wiki/API API], the SOA implements the interfaces using the protocols and functionality. SOA separates functions into unique entities or services, which are accessed in a network by the users to combine and reuse them to develop the applications.

==Why SOA?==

Various businesses in the field of [http://en.wikipedia.org/wiki/Information_technology Information Technology] have to justify their projects with a return on their investments. This creates a pressure in Information Technology by making it a demanding field. Information Technology needs to have requirements in a way that it has to responsive and adapt to the changing requirements.

Information Technology companies must also be able to provide the services that are compatible with other services making it interoperable, thus creating dynamic services. Moreover, Information Technology has to face demands to bring new commercial services to a much wider array of customers. Customers may access services through web interfaces, or may be part of a supply chain that needs to decrease the time and cost of manufacturing.

Thus, Information Technology companies are always on the look out for solutions that will help them meet the above demands – without having to spend a lot of money. [http://en.wikipedia.org/wiki/Service_oriented_architecture Service Oriented Architecture] offers a solution to satisfy the above needs of the industry

==SOA-Benifits==
In architectural terms, a modern architectural design should be Service Oriented, loosely coupled, driven by events, able to support both integration and assembly, aligned with valuable life cycle support processes, and able to leverage existing infrastructure and applications.

When it comes to Service Oriented Architecture, it tends to offer a variety of different advantages over more traditional methods of distributing computing. These include
i) business services across several platforms
ii) location independence
iii) authentication as well as authorization support on different platforms
iv ) loosely coupled approach, dynamic search and connectivity to other services.

=Design Patterns in SOA=
A [http://en.wikipedia.org/wiki/Design_pattern design pattern] is a general reusable solution to a commonly occurring problem in software design. A design pattern is not a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be applied in different scenarios. Design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved.

Design patterns play a major role in SOA. The implementation and deployment of SOA designs provide different challenges during product development life cycle.Such challenges may make projects to be discontinued. Design patterns help in overcoming these problems by providing a solution to the problems posed. Each SOA design pattern provides a design solution in support of
successfully applying service orientation and establishing a quality service-oriented architecture

=Design Patterns proposed =

The proposed Design Patterns for SOA fall in to following categories. They are listed below and corresponding patterns in
each category are given. Detailed explanation of the design patterns given in the example can be found in the link provided for each category.

[http://www.soapatterns.org/masterlist_c.asp#ch6 Foundational Inventory Patterns]

These design patterns focus on providing solutions to the problems like maximizing re-composition and avoiding redundant logic.

Examples include Enterprise Inventory, Domain Inventory, Service Normalization, Logic Centralization, Service Layers Canonical Protocol, Canonical Schema

[http://www.soapatterns.org/masterlist_c.asp#ch7 Logical Inventory Layer Patterns]

These design patterns provide the solution to the problem of how can business logic be separated, reused, and governed independently.

Examples for this category are Utility Abstraction, Entity Abstraction, Process Abstraction

[http://www.soapatterns.org/masterlist_c.asp#ch8 Inventory Centralization Patterns]

These patterns focus on providing solution for aspect of governing business logic etc

Examples for this category are Process Centralization, Schema Centralization, Policy Centralization, Rules Centralization.

[http://www.soapatterns.org/masterlist_c.asp#ch9 Inventory Implementation Patterns]

These patterns help to solve implementation problems like limitations introduced by communication technology. Example like a single protocol may not accommodate all requirements etc

Examples for this category are Dual Protocols, Canonical Resources, State Repository, Stateful Services, Service Grid, Inventory Endpoint, Cross-Domain Utility Layer

[http://www.soapatterns.org/masterlist_c.asp#ch10 Inventory Governance Patterns]

The patterns deal with the governance problems caused by service contract within the same service inventory

Examples include Canonical Expression, Metadata Centralization, Canonical Versioning

[http://www.soapatterns.org/masterlist_c.asp#ch11 Foundational Service Patterns]

The patterns proposed in this category focus on solving large business problems without having to build a stand alone solution.

Examples for this category are Functional Decomposition, Service Encapsulation, Agnostic Context, Non-Agnostic Context, Agnostic Capability

[http://www.soapatterns.org/masterlist_c.asp#ch12 Service Implementation Patterns]

The patterns in this category focus on improving the realiability and availability of the service

Examples include Service Facade, Redundant Implementation, Service Data Replication, Partial State Deferral, Partial Validation, UI Mediator

[http://www.soapatterns.org/masterlist_c.asp#ch13 Service Security Patterns]

The patterns proposed in this category deal with the problem of data encapsulation and security aspects.

Examples for this category are Exception Shielding, Message Screening, Trusted Subsystem, Service Perimeter Guard

[http://www.soapatterns.org/masterlist_c.asp#ch14 Service Contract Design Patterns]

The patterns proposed in this category focus on providing solution for how to make the service contract suitable for all potential customers,make it aligned with other services etc

Examples for this category are Decoupled Contract, Contract Centralization, Contract De normalization, Concurrent Contracts, Validation Abstraction

[http://www.soapatterns.org/masterlist_c.asp#ch15 Legacy Encapsulation Patterns]

The patterns proposed deals with the problems in legacy systems like processing of data contained in flat files, redundancy resulting in delivery to multiple channels etc

Examples for this category are Legacy Wrapper, Multi-Channel Endpoint, File Gateway

[http://www.soapatterns.org/masterlist_c.asp#ch16 Service Governance Patterns]

These patterns provide solution for problems like updating the customers with changed service so that they are not affected, modifications in service etc

Examples for this category are Compatible Change, Version Identification, Termination Notification, Service Refactoring, Service Decomposition, Proxy Capability, Decomposed Capability, Distributed Capability

[http://www.soapatterns.org/masterlist_c.asp#ch17 Capability Composition Patterns]

The pattern proposed focuses on the problem of How can a service capability solve a problem that requires logic outside of the service boundary and How can the same capability be used to help solve multiple problems?

Examples for this category are Capability Composition, Capability Recomposition

[http://www.soapatterns.org/masterlist_c.asp#ch18 Service Messaging Patterns]

The patterns proposed in this category focus on setting up of message framework for transfer of data.

Examples in this category are Service Messaging, Messaging Metadata, Service Agent, Intermediate Routing, State Messaging, Service Callback, Service Instance Routing, Asynchronous Queuing, Reliable Messaging, Event-Driven Messaging.

[http://www.soapatterns.org/masterlist_c.asp#ch19 Composition Implementation Patterns]

The patterns proposed in this category focus on problems during runtime like runtime activities that span multiple services fail, the parent business task is incomplete etc

Examples for this category are Agnostic SubController, Composition Autonomy, Atomic Service Transaction, Compensating ServiceTransaction

[http://www.soapatterns.org/masterlist_c.asp#ch20 Service Interaction Security Patterns]

The proposed patterns in this category are focused on security methods like encryption,decryption,authenticating the data,consumer and service

Examples include Data Confidentiality, Data Origin Authentication, Direct Authentication, Brokered Authentication

[http://www.soapatterns.org/masterlist_c.asp#ch21 Transformation Patterns]

The Patterns proposed in this category concrete on how data from one data model can be dynamically converted to comply to a different data model.

Examples for this category are Data Model Transformation, Data Format Transformation, Protocol Bridging

[http://www.soapatterns.org/masterlist_c.asp#ch22 Common Compound Design Patterns]

A compound pattern is a coarse-grained pattern comprised of a set of finer-grained patterns.

Examples include Orchestration, Enterprise Service Bus, Service Broker, Canonical Schema Bus, Official Endpoint, Federated Endpoint Layer, Three-Layer Inventory

=Example Design Patterns =

The following section describes five design patterns which are utilized in SOA. The described patterns provide the problem and corresponding solution.The figures for the following examples are taken from corresponding sections of [http://www.soapatterns.org/masterlist_a.asp soapatterns.org]

==Canonical protocol==

[[Image:Canonicalpattern.jpg.png]]

''Canonical Protocol Figure as given in SOA Patterns website''

Problem: Services that support different communication technologies compromise interoperability, limit the quantity of potential consumers, and introduce the need for undesirable protocol bridging measures.

Solution: The architecture establishes a single communications technology as the sole or primary medium by which services can interact.

From the above figure it is observed that the services are delivered by three different communication technologies A,B and C.These services are made to conform to one centralized communications technology, making them technologically compatible.with this these services can be delivered to consumers without much difficulty

==Dual protocol==

[[Image:dualprotocol.png]]

''Dual Protocol figure as given in SOA Pattern Official Website''

Problem: Canonical Protocol requires that all services conform to the use of the same communications technology; however, a single protocol may not be able to accommodate all service requirements, thereby introducing limitations.

Solution: The service inventory architecture is designed to support services based on primary and secondary protocols.

Regardless of protocol, all services must invoke each other via their official service contracts (A, B). Bypassing the contract may seem convenient when the underlying service logic of the primary service supports the same protocol as the secondary service (C), but it is an anti-pattern that will eventually inhibit the application of this pattern and further weaken the overall service inventory foundation.

==Protocol Bridging==

[[Image:protocolbridging.png]]

''Protocol Bridging Figure as given in the SOA Patterns Official Website''

Problem: Services using different communication protocols or different versions of the same protocol cannot exchange data.

Solution: Bridging logic is introduced to enable communication between different communication protocols by dynamically converting one protocol to another at runtime.

From the above figure it can be noticed that the consumer programs interact with a middle-tier broker that provides protocol bridging features.The consumer programs may be using different protocols like [http://java.sun.com/products/jms/ JMS] or SOAP 1.1.In order to translate the two incompatible protocols in to the required SOAP 1,2 with HTTP separate protocol adapters are used in the broker. The broker then transmits the messages to the service on behalf of the consumers.Therefore the protocol bridging is achieved.

==UI Mediator==

[[Image:uimediator.png]]

''Figure of UI Mediator as given in Official SOA Patterns Website''

Problem: Because the behavior of individual services can vary depending on their design,runtime usage, and the workload required to carry out a given capability, the consistency with which a service-oriented solution can respond to requests originating from a user-interface can fluctuate, leading to a poor user experience.

Solution: Establish mediator logic solely responsible for ensuring timely interaction and feedback with user-interfaces and presentation logic.

In this method as can be observed from the figure the three services A,B and C work behind the scenes to complete the given task.The mediator service (D) regularly updates the user interface there by hiding the underlying logic to the consumer.

==Service Facade==

[[Image:service_facade.png]]

''Figure for Service Facade as given in the official SOA Pattern Site''

Problem: The coupling of the core service logic to contracts and implementation resources can inhibit its evolution and negatively impact service consumers.

Solution: A service facade component is used to abstract a part of the service architecture with negative coupling potential.

Facade logic is placed in between the contract and the core service logic. This allows the core service logic to remain decoupled from the contract.The objective of loose coupling is achieved by this process.the core logic abstraction is obtained by this way.

=Similarities and Differences Between Patterns for SOA and Traditional pattens proposed by GoF=

The Gang of Four(Gof) comprising of Eric Gamma, Richard Helm, Ralph Johnson, and John Vlissides have documented the design patterns that were followed by Software developers and architects in object oriented space. They have documented 23 design patterns which are collectively called as Traditional design patterns.

The design patterns in SOA are similiar in some aspects to the traditional patterns.They also differ from the traditional patterns. The similiarities and differences between them are provided in this section

==Differences==

The differences between the SOA design patterns and traditional design patterns have been come up based on the individual functionality that each pattern provide. Following are the differences,

1) The [http://en.wikipedia.org/wiki/Composite_pattern composite pattern] organizes the objects in the manner to represent the part-whole hierarchies in a traditional two-tier hierarchy.

The [http://www.soapatterns.org/agnostic_subcontroller.asp agnostic sub-controller] implements the service composability but it differs from the composite pattern in such a way that cross-entity functionality is abstracted and made accessible through the sub –controller capability.

For instance, the traditional composite pattern has the object representing a part-whole hierarchy as in the below figure of graphic class which has draw(). If we require a cross-entity functionality as in the below figure, we require a colored rectangle, we require the functionality fill() of color class. Hence the sub-controller module is created which has the functionality of different parents, thus making it reusable.

''Figure to illustrate above difference''

[[Image:Composite_example.png]]

2)
The traditional [http://en.wikipedia.org/wiki/Bridge_pattern bridge pattern] separates the abstraction from its implementation in order to vary independently. Whereas the [http://www.soapatterns.org/canonical_protocol.asp canonical protocol] avoids the protocol bridging in such a way that there is a single communication technology through which the services can interact.

In the below figure of bridge pattern, the relationship between the abstraction and implementor is bridge and it results the implementor to vary independently from the abstraction by having different ConcreteImplementor. The canonical protocol avoids the variation by having a single communication technology between different objects.

''Figure to illustrate above difference''

[[Image:Traditional_bridge.png]]

''Figure for Traditional bridge pattern (Source: Elements of Reusable Object-Oriented Software by Gang of Four)''

For canonical protocol refer to the explanation given in example design patterns

3) The traditional [http://en.wikipedia.org/wiki/Builder_pattern builder pattern] decouples the construction of the object from its representation so that the same construction process can be used to develop different representations. The different representations (contracts) are addressed in SOA by the [http://www.soapatterns.org/concurrent_contracts.asp Concurrent Contracts] with the application of [http://www.soapatterns.org/service_facade.asp Service-façade] design pattern. With service-façade design pattern, an abstraction is created to support the interaction between different contracts. As a result, different contracts can be created for a single service.

In the below figure, the conversion of the text document is separated from the reader of RTF document, so that the text document can be represented in different forms like ASCIIText, TeXText and TextWidget. The different representation is achieved by decoupling of construction and abstraction. In the case of concurrent contracts pattern, the different contracts or services (invoices) are created for different consumer through service-façade by creating a new abstraction.

[[Image:Builder.png]]

''Figure for Traditional Builder pattern (Source: Elements of Reusable Object-Oriented Software by Gang of Four)''

[[Image:Concurrent_pattern.png]]

''Figure for Concurrent Contracts pattern (Source: SOA Patterns website)''

==Similarities==
1) The [http://www.soapatterns.org/service_facade.asp Service-façade] design pattern is similar to the [http://en.wikipedia.org/wiki/Facade_pattern façade] (traditional) pattern in the manner that it implements the façade logic which is creating an abstraction for intra-communication within objects to the service architecture. The advantage by adding the façade logic to the service architecture is that it preserves the underlying logic from run-time changes.

2) The [http://www.soapatterns.org/ui_mediator.asp UI Mediator] design pattern implements the [http://en.wikipedia.org/wiki/Mediator_pattern mediator] logic of traditional mediator pattern. The mediator logic aims to provide the user responses in a way that user understands, independently of what the underlying services perform.

3) The [http://www.soapatterns.org/intermediate_routing.asp Intermediate routing] pattern in SOA is similar to [http://en.wikipedia.org/wiki/Decorator_pattern Decorator pattern] (traditional) in the functionality that it adds the required logic at run-time. The decorator adds the additional functionality to the object at run-time. The intermediate routing pattern is about placing the routing logic to address the run-time scenarios.

4)The [http://www.soapatterns.org/capability_composition.asp Capability Composition] pattern in SOA implements the [http://en.wikipedia.org/wiki/Composite_pattern Composite pattern] (traditional). The Capability Composition is about composing one or more capabilities outside the service’s context to address the large, complex problem.

5) The [http://www.soapatterns.org/decoupled_contract.asp Decoupled Contract] pattern implements the traditional [http://en.wikipedia.org/wiki/Bridge_pattern Bridge pattern] in the manner that service contract is separated from the implementation. The Bridge pattern decouples the abstraction from implementation to facilitate the variation of both (abstraction and implementation).

6) The [http://www.soapatterns.org/legacy_wrapper.asp Legacy Wrapper] pattern is related to traditional [http://en.wikipedia.org/wiki/Adapter_pattern Adapter pattern]. The Legacy Wrapper pattern protects the legacy logic by providing a standard service that takes of protecting the legacy details by encapsulating, extraction or elimination. The encapsulation, extraction or elimination is done in order to change the service as the consumer requires it. This is related to adapter in a way that it converts the interface of one class to another as the client expects.

=Summary=
The various patterns in Service oriented Architecture which have been currently proposed were studied and an attempt was made to document all of them by categories.Few detailed examples are documented to get an understanding of the underlying process.Specific comparison of design patterns in SOA domain and corresponding traditional patterns has been carried out.The design patterns in SOA are still under development and many patterns are coming up due to vast technology used in this domain.

=Glossary=

1.Serive : "A service is a discoverable resource that executes a repeatable task, and is described by an externalized service specification."

2.[http://www.ibm.com/developerworks/webservices/library/ws-soa-term1/ SOA Terminology]: SOA Terminology is all about Service, architecture, governance and business terms.

3.SOA :[http://en.wikipedia.org/wiki/Service-oriented_architecture Service oriented Architecture]: SOA is an architectural style used for creating IT architecture that supports a strong relationship between business and information systems.

4.API :[http://en.wikipedia.org/wiki/Application_programming_interface Application programming interface]: An interface used by the application to obtain the services from libraries or operating system.

5.SOAP :[http://en.wikipedia.org/wiki/SOAP Simple Object Access Protocol]: A protocol used for the exchange of structured information in Web Services implementation.

6.HTTP :[http://en.wikipedia.org/wiki/HyperText_Transfer_Protocol Hypertext Transfer Protocol]: A protocol used for distributing hypertext documents (mostly used in the web pages implementation)

7.GoF :[http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Gang of Four]: Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides

8.[http://soaglossary.com/ SOA Glossory]: Comprehensive list of glossaries used in SOA domain.

=References=

1.[http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Design patterns for object oriented software]

2.[http://en.wikipedia.org/wiki/Service-oriented_architecture#Introduction Service Oriented Architecture]

3.[http://www.exforsys.com/tutorials/soa/soa-definitions-and-certification.html SOA Tutorial]

4.[http://www.soapatterns.org/ soa design patterns]

5.[http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29 design pattern]

6.[http://www.oracle.com/technologies/soa/center.html oracle SOA centre]

7.[http://www.ibm.com/developerworks/webservices/library/ws-soa-term1/ IBMs SOA Contributions]

8.[http://www.oracle.com/technology/pub/articles/erl_soa_design_patterns_app_sequences.html SOA Design patterns application sequences by oracle]

9.SOA Design Patterns by Thomas Erl

CSC/ECE 517 Fall 2009/wiki2 16 rs

2009-10-15T01:16:09Z

Screenit: /* Design Patterns proposed */

CSC/ECE 517 Fall 2009/wiki2 16 rs

SOA provides another view of providing functionality based upon services offered in terms of protocols and a specific API. Research and report on what patterns have been proposed and are utilized within this domain. How do they differ from traditional design patterns proposed by Eric Gamma, Richard Helm, Ralph Johnson, and John Vlissides? How are they similar?

----
=Introduction=

This article focuses on the design patterns which are proposed and utilized in the [http://en.wikipedia.org/wiki/Service_oriented_architecture Service Oriented Architecture]. As the SOA provides its services through the protocols and API, this article throws light on the design patterns that specifically provide services through protocols like [http://www.soapatterns.org/canonical_protocol.asp Canonical protocol], [http://www.soapatterns.org/dual_protocols.asp Dual protocols] and [http://www.soapatterns.org/protocol_bridging.asp Protocol Bridging]. In a broader perspective, other design patterns have been explained tersely. In addition to explanation of the SOA design patterns, this compares the SOA design patterns with the traditional design patterns proposed by the ‘Gang of Four’ (Eric Gamma, Richard Helm, Ralph Johnson, and John Vlissides) and comes up with the differences and similarities between them.

=Service Oriented Architecture-An Overview=

==SOA-Definition==

A [http://en.wikipedia.org/wiki/Service_oriented_architecture Service Oriented Architecture] is an architecture that provides collection of services. These services need to inter-operate with each other to provide the functionality. This architecture requires a loose coupling with operating systems and other technologies that form the basis of the application. The loose coupling between services is required because each interaction has to be independent of the other. The communication between services could be either simple data being passed or it could be either an activity coordinated between distinct entities or services. Some means of interoperability is required to provide the services in larger terms. Instead of defining the [http://en.wikipedia.org/wiki/API API], the SOA implements the interfaces using the protocols and functionality. SOA separates functions into unique entities or services, which are accessed in a network by the users to combine and reuse them to develop the applications.

==Why SOA?==

Various businesses in the field of [http://en.wikipedia.org/wiki/Information_technology Information Technology] have to justify their projects with a return on their investments. This creates a pressure in Information Technology by making it a demanding field. Information Technology needs to have requirements in a way that it has to responsive and adapt to the changing requirements.

Information Technology companies must also be able to provide the services that are compatible with other services making it interoperable, thus creating dynamic services. Moreover, Information Technology has to face demands to bring new commercial services to a much wider array of customers. Customers may access services through web interfaces, or may be part of a supply chain that needs to decrease the time and cost of manufacturing.

Thus, Information Technology companies are always on the look out for solutions that will help them meet the above demands – without having to spend a lot of money. [http://en.wikipedia.org/wiki/Service_oriented_architecture Service Oriented Architecture] offers a solution to satisfy the above needs of the industry

==SOA-Benifits==
In architectural terms, a modern architectural design should be Service Oriented, loosely coupled, driven by events, able to support both integration and assembly, aligned with valuable life cycle support processes, and able to leverage existing infrastructure and applications.

When it comes to Service Oriented Architecture, it tends to offer a variety of different advantages over more traditional methods of distributing computing. These include
i) business services across several platforms
ii) location independence
iii) authentication as well as authorization support on different platforms
iv ) loosely coupled approach, dynamic search and connectivity to other services.

=Design Patterns in SOA=
A [http://en.wikipedia.org/wiki/Design_pattern design pattern] is a general reusable solution to a commonly occurring problem in software design. A design pattern is not a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be applied in different scenarios. Design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved.

Design patterns play a major role in SOA. The implementation and deployment of SOA designs provide different challenges during product development life cycle.Such challenges may make projects to be discontinued. Design patterns help in overcoming these problems by providing a solution to the problems posed. Each SOA design pattern provides a design solution in support of
successfully applying service orientation and establishing a quality service-oriented architecture

=Design Patterns proposed =

The proposed Design Patterns for SOA fall in to following categories. They are listed below and corresponding patterns in
each category are given. Detailed explanation of the design patterns given in the example can be found in the link provided for each category.

[http://www.soapatterns.org/masterlist_c.asp#ch6 Foundational Inventory Patterns]

These design patterns focus on providing solutions to the problems like maximizing re-composition and avoiding redundant logic.

Examples include Enterprise Inventory, Domain Inventory, Service Normalization, Logic Centralization, Service Layers Canonical Protocol, Canonical Schema

[http://www.soapatterns.org/masterlist_c.asp#ch7 Logical Inventory Layer Patterns]

These design patterns provide the solution to the problem of how can business logic be separated, reused, and governed independently.

Examples for this category are Utility Abstraction, Entity Abstraction, Process Abstraction

[http://www.soapatterns.org/masterlist_c.asp#ch8 Inventory Centralization Patterns]

These patterns focus on providing solution for aspect of governing business logic etc

Examples for this category are Process Centralization, Schema Centralization, Policy Centralization, Rules Centralization.

[http://www.soapatterns.org/masterlist_c.asp#ch9 Inventory Implementation Patterns]

These patterns help to solve implementation problems like limitations introduced by communication technology. Example like a single protocol may not accommodate all requirements etc

Examples for this category are Dual Protocols, Canonical Resources, State Repository, Stateful Services, Service Grid, Inventory Endpoint, Cross-Domain Utility Layer

[http://www.soapatterns.org/masterlist_c.asp#ch10 Inventory Governance Patterns]

The patterns deal with the governance problems caused by service contract within the same service inventory

Examples include Canonical Expression, Metadata Centralization, Canonical Versioning

[http://www.soapatterns.org/masterlist_c.asp#ch11 Foundational Service Patterns]

The patterns proposed in this category focus on solving large business problems without having to build a stand alone solution.

Examples for this category are Functional Decomposition, Service Encapsulation, Agnostic Context, Non-Agnostic Context, Agnostic Capability

[http://www.soapatterns.org/masterlist_c.asp#ch12 Service Implementation Patterns]

The patterns in this category focus on improving the realiability and availability of the service

Examples include Service Facade, Redundant Implementation, Service Data Replication, Partial State Deferral, Partial Validation, UI Mediator

[http://www.soapatterns.org/masterlist_c.asp#ch13 Service Security Patterns]

The patterns proposed in this category deal with the problem of data encapsulation and security aspects.

Examples for this category are Exception Shielding, Message Screening, Trusted Subsystem, Service Perimeter Guard

[http://www.soapatterns.org/masterlist_c.asp#ch14 Service Contract Design Patterns]

The patterns proposed in this category focus on providing solution for how to make the service contract suitable for all potential customers,make it aligned with other services etc

Examples for this category are Decoupled Contract, Contract Centralization, Contract De normalization, Concurrent Contracts, Validation Abstraction

[http://www.soapatterns.org/masterlist_c.asp#ch15 Legacy Encapsulation Patterns]

The patterns proposed deals with the problems in legacy systems like processing of data contained in flat files, redundancy resulting in delivery to multiple channels etc

Examples for this category are Legacy Wrapper, Multi-Channel Endpoint, File Gateway

[http://www.soapatterns.org/masterlist_c.asp#ch16 Service Governance Patterns]

These patterns provide solution for problems like updating the customers with changed service so that they are not affected, modifications in service etc

Examples for this category are Compatible Change, Version Identification, Termination Notification, Service Refactoring, Service Decomposition, Proxy Capability, Decomposed Capability, Distributed Capability

[http://www.soapatterns.org/masterlist_c.asp#ch17 Capability Composition Patterns]

The pattern proposed focuses on the problem of How can a service capability solve a problem that requires logic outside of the service boundary and How can the same capability be used to help solve multiple problems?

Examples for this category are Capability Composition, Capability Recomposition

[http://www.soapatterns.org/masterlist_c.asp#ch18 Service Messaging Patterns]

The patterns proposed in this category focus on setting up of message framework for transfer of data.

Examples in this category are Service Messaging, Messaging Metadata, Service Agent, Intermediate Routing, State Messaging, Service Callback, Service Instance Routing, Asynchronous Queuing, Reliable Messaging, Event-Driven Messaging.

[http://www.soapatterns.org/masterlist_c.asp#ch19 Composition Implementation Patterns]

The patterns proposed in this category focus on problems during runtime like runtime activities that span multiple services fail, the parent business task is incomplete etc

Examples for this category are Agnostic SubController, Composition Autonomy, Atomic Service Transaction, Compensating ServiceTransaction

[http://www.soapatterns.org/masterlist_c.asp#ch20 Service Interaction Security Patterns]

The proposed patterns in this category are focused on security methods like encryption,decryption,authenticating the data,consumer and service

Examples include Data Confidentiality, Data Origin Authentication, Direct Authentication, Brokered Authentication

[http://www.soapatterns.org/masterlist_c.asp#ch21 Transformation Patterns]

The Patterns proposed in this category concrete on how data from one data model can be dynamically converted to comply to a different data model.

Examples for this category are Data Model Transformation, Data Format Transformation, Protocol Bridging

[http://www.soapatterns.org/masterlist_c.asp#ch22 Common Compound Design Patterns]

A compound pattern is a coarse-grained pattern comprised of a set of finer-grained patterns.

Examples include Orchestration, Enterprise Service Bus, Service Broker, Canonical Schema Bus, Official Endpoint, Federated Endpoint Layer, Three-Layer Inventory

=Example Design Patterns =

The following section describes five design patterns which are utilized in SOA. The described patterns provide the problem and corresponding solution.The figures for the following examples are taken from corresponding sections of [http://www.soapatterns.org/masterlist_a.asp soapatterns.org]

==Canonical protocol==

[[Image:Canonicalpattern.jpg.png]]

''Canonical Protocol Figure as given in SOA Patterns website''

Problem: Services that support different communication technologies compromise interoperability, limit the quantity of potential consumers, and introduce the need for undesirable protocol bridging measures.

Solution: The architecture establishes a single communications technology as the sole or primary medium by which services can interact.

From the above figure it is observed that the services are delivered by three different communication technologies A,B and C.These services are made to conform to one centralized communications technology, making them technologically compatible.with this these services can be delivered to consumers without much difficulty

==Dual protocol==

[[Image:dualprotocol.png]]

''Dual Protocol figure as given in SOA Pattern Official Website''

Problem: Canonical Protocol requires that all services conform to the use of the same communications technology; however, a single protocol may not be able to accommodate all service requirements, thereby introducing limitations.

Solution: The service inventory architecture is designed to support services based on primary and secondary protocols.

Regardless of protocol, all services must invoke each other via their official service contracts (A, B). Bypassing the contract may seem convenient when the underlying service logic of the primary service supports the same protocol as the secondary service (C), but it is an anti-pattern that will eventually inhibit the application of this pattern and further weaken the overall service inventory foundation.

==Protocol Bridging==

[[Image:protocolbridging.png]]

''Protocol Bridging Figure as given in the SOA Patterns Official Website''

Problem: Services using different communication protocols or different versions of the same protocol cannot exchange data.

Solution: Bridging logic is introduced to enable communication between different communication protocols by dynamically converting one protocol to another at runtime.

From the above figure it can be noticed that the consumer programs interact with a middle-tier broker that provides protocol bridging features.The consumer programs may be using different protocols like [http://java.sun.com/products/jms/ JMS] or SOAP 1.1.In order to translate the two incompatible protocols in to the required SOAP 1,2 with HTTP separate protocol adapters are used in the broker. The broker then transmits the messages to the service on behalf of the consumers.Therefore the protocol bridging is achieved.

==UI Mediator==

[[Image:uimediator.png]]

''Figure of UI Mediator as given in Official SOA Patterns Website''

Problem: Because the behavior of individual services can vary depending on their design,runtime usage, and the workload required to carry out a given capability, the consistency with which a service-oriented solution can respond to requests originating from a user-interface can fluctuate, leading to a poor user experience.

Solution: Establish mediator logic solely responsible for ensuring timely interaction and feedback with user-interfaces and presentation logic.

In this method as can be observed from the figure the three services A,B and C work behind the scenes to complete the given task.The mediator service (D) regularly updates the user interface there by hiding the underlying logic to the consumer.

==Service Facade==

[[Image:service_facade.png]]

''Figure for Service Facade as given in the official SOA Pattern Site''

Problem: The coupling of the core service logic to contracts and implementation resources can inhibit its evolution and negatively impact service consumers.

Solution: A service facade component is used to abstract a part of the service architecture with negative coupling potential.

Facade logic is placed in between the contract and the core service logic. This allows the core service logic to remain decoupled from the contract.The objective of loose coupling is achieved by this process.the core logic abstraction is obtained by this way.

=Similarities and Differences Between Patterns for SOA and Traditional pattens proposed by GoF=

The Gang of Four(Gof) comprising of Eric Gamma, Richard Helm, Ralph Johnson, and John Vlissides have documented the design patterns that were followed by Software developers and architects in object oriented space. They have documented 23 design patterns which are collectively called as Traditional design patterns.

The design patterns in SOA are similiar in some aspects to the traditional patterns.They also differ from the traditional patterns. The similiarities and differences between them are provided in this section

==Differences==

The differences between the SOA design patterns and traditional design patterns have been come up based on the individual functionality that each pattern provide. Following are the differences,

1) The [http://en.wikipedia.org/wiki/Composite_pattern composite pattern] organizes the objects in the manner to represent the part-whole hierarchies in a traditional two-tier hierarchy.

The [http://www.soapatterns.org/agnostic_subcontroller.asp agnostic sub-controller] implements the service composability but it differs from the composite pattern in such a way that cross-entity functionality is abstracted and made accessible through the sub –controller capability.

For instance, the traditional composite pattern has the object representing a part-whole hierarchy as in the below figure of graphic class which has draw(). If we require a cross-entity functionality as in the below figure, we require a colored rectangle, we require the functionality fill() of color class. Hence the sub-controller module is created which has the functionality of different parents, thus making it reusable.

''Figure to illustrate above difference''

[[Image:Composite_example.png]]

2)
The traditional [http://en.wikipedia.org/wiki/Bridge_pattern bridge pattern] separates the abstraction from its implementation in order to vary independently. Whereas the [http://www.soapatterns.org/canonical_protocol.asp canonical protocol] avoids the protocol bridging in such a way that there is a single communication technology through which the services can interact.

In the below figure of bridge pattern, the relationship between the abstraction and implementor is bridge and it results the implementor to vary independently from the abstraction by having different ConcreteImplementor. The canonical protocol avoids the variation by having a single communication technology between different objects.

''Figure to illustrate above difference''

[[Image:Traditional_bridge.png]]

''Figure for Traditional bridge pattern (Source: Elements of Reusable Object-Oriented Software by Gang of Four)''

For canonical protocol refer to the explanation given in example design patterns

3) The traditional [http://en.wikipedia.org/wiki/Builder_pattern builder pattern] decouples the construction of the object from its representation so that the same construction process can be used to develop different representations. The different representations (contracts) are addressed in SOA by the [http://www.soapatterns.org/concurrent_contracts.asp Concurrent Contracts] with the application of [http://www.soapatterns.org/service_facade.asp Service-façade] design pattern. With service-façade design pattern, an abstraction is created to support the interaction between different contracts. As a result, different contracts can be created for a single service.

In the below figure, the conversion of the text document is separated from the reader of RTF document, so that the text document can be represented in different forms like ASCIIText, TeXText and TextWidget. The different representation is achieved by decoupling of construction and abstraction. In the case of concurrent contracts pattern, the different contracts or services (invoices) are created for different consumer through service-façade by creating a new abstraction.

[[Image:Builder.png]]

''Figure for Traditional Builder pattern (Source: Elements of Reusable Object-Oriented Software by Gang of Four)''

[[Image:Concurrent_pattern.png]]

''Figure for Concurrent Contracts pattern (Source: SOA Patterns website)''

==Similarities==
1) The [http://www.soapatterns.org/service_facade.asp Service-façade] design pattern is similar to the [http://en.wikipedia.org/wiki/Facade_pattern façade] (traditional) pattern in the manner that it implements the façade logic which is creating an abstraction for intra-communication within objects to the service architecture. The advantage by adding the façade logic to the service architecture is that it preserves the underlying logic from run-time changes.

2) The [http://www.soapatterns.org/ui_mediator.asp UI Mediator] design pattern implements the [http://en.wikipedia.org/wiki/Mediator_pattern mediator] logic of traditional mediator pattern. The mediator logic aims to provide the user responses in a way that user understands, independently of what the underlying services perform.

3) The [http://www.soapatterns.org/intermediate_routing.asp Intermediate routing] pattern in SOA is similar to [http://en.wikipedia.org/wiki/Decorator_pattern Decorator pattern] (traditional) in the functionality that it adds the required logic at run-time. The decorator adds the additional functionality to the object at run-time. The intermediate routing pattern is about placing the routing logic to address the run-time scenarios.

4)The [http://www.soapatterns.org/capability_composition.asp Capability Composition] pattern in SOA implements the [http://en.wikipedia.org/wiki/Composite_pattern Composite pattern] (traditional). The Capability Composition is about composing one or more capabilities outside the service’s context to address the large, complex problem.

5) The [http://www.soapatterns.org/decoupled_contract.asp Decoupled Contract] pattern implements the traditional [http://en.wikipedia.org/wiki/Bridge_pattern Bridge pattern] in the manner that service contract is separated from the implementation. The Bridge pattern decouples the abstraction from implementation to facilitate the variation of both (abstraction and implementation).

6) The [http://www.soapatterns.org/legacy_wrapper.asp Legacy Wrapper] pattern is related to traditional [http://en.wikipedia.org/wiki/Adapter_pattern Adapter pattern]. The Legacy Wrapper pattern protects the legacy logic by providing a standard service that takes of protecting the legacy details by encapsulating, extraction or elimination. The encapsulation, extraction or elimination is done in order to change the service as the consumer requires it. This is related to adapter in a way that it converts the interface of one class to another as the client expects.

=Summary=
The various patterns in Service oriented Architecture which have been currently proposed were studied and an attempt was made to document all of them by categories.Few detailed examples are documented to get an understanding of the underlying process.Specific comparison of design patterns in SOA domain and corresponding traditional patterns has been carried out.The design patterns in SOA are still under development and many patterns are coming up due to vast technology used in this domain.

=Glossary=

1.Serive : "A service is a discoverable resource that executes a repeatable task, and is described by an externalized service specification."

2.[http://www.ibm.com/developerworks/webservices/library/ws-soa-term1/ SOA Terminology]

3.SOA :[http://en.wikipedia.org/wiki/Service-oriented_architecture Service oriented Architecture]

4.API :[http://en.wikipedia.org/wiki/Application_programming_interface Application programming interface]

5.SOAP :[http://en.wikipedia.org/wiki/SOAP Simple Object Access Protocol]

6.HTTP :[http://en.wikipedia.org/wiki/HyperText_Transfer_Protocol Hypertext Transfer Protocol]

7.GoF :[http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Gang of Four]

8.[http://soaglossary.com/ SOA Glossory]

=References=

1.[http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Design patterns for object oriented software]

2.[http://en.wikipedia.org/wiki/Service-oriented_architecture#Introduction Service Oriented Architecture]

3.[http://www.exforsys.com/tutorials/soa/soa-definitions-and-certification.html SOA Tutorial]

4.[http://www.soapatterns.org/ soa design patterns]

5.[http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29 design pattern]

6.[http://www.oracle.com/technologies/soa/center.html oracle SOA centre]

7.[http://www.ibm.com/developerworks/webservices/library/ws-soa-term1/ IBMs SOA Contributions]

8.[http://www.oracle.com/technology/pub/articles/erl_soa_design_patterns_app_sequences.html SOA Design patterns application sequences by oracle]

9.SOA Design Patterns by Thomas Erl

CSC/ECE 517 Fall 2009/wiki2 16 rs

2009-10-15T00:57:14Z

Screenit: /* Differences */

CSC/ECE 517 Fall 2009/wiki2 16 rs

SOA provides another view of providing functionality based upon services offered in terms of protocols and a specific API. Research and report on what patterns have been proposed and are utilized within this domain. How do they differ from traditional design patterns proposed by Eric Gamma, Richard Helm, Ralph Johnson, and John Vlissides? How are they similar?

----
=Introduction=

This article focuses on the design patterns which are proposed and utilized in the [http://en.wikipedia.org/wiki/Service_oriented_architecture Service Oriented Architecture]. As the SOA provides its services through the protocols and API, this article throws light on the design patterns that specifically provide services through protocols like [http://www.soapatterns.org/canonical_protocol.asp Canonical protocol], [http://www.soapatterns.org/dual_protocols.asp Dual protocols] and [http://www.soapatterns.org/protocol_bridging.asp Protocol Bridging]. In a broader perspective, other design patterns have been explained tersely. In addition to explanation of the SOA design patterns, this compares the SOA design patterns with the traditional design patterns proposed by the ‘Gang of Four’ (Eric Gamma, Richard Helm, Ralph Johnson, and John Vlissides) and comes up with the differences and similarities between them.

=Service Oriented Architecture-An Overview=

==SOA-Definition==

A [http://en.wikipedia.org/wiki/Service_oriented_architecture Service Oriented Architecture] is an architecture that provides collection of services. These services need to inter-operate with each other to provide the functionality. This architecture requires a loose coupling with operating systems and other technologies that form the basis of the application. The loose coupling between services is required because each interaction has to be independent of the other. The communication between services could be either simple data being passed or it could be either an activity coordinated between distinct entities or services. Some means of interoperability is required to provide the services in larger terms. Instead of defining the [http://en.wikipedia.org/wiki/API API], the SOA implements the interfaces using the protocols and functionality. SOA separates functions into unique entities or services, which are accessed in a network by the users to combine and reuse them to develop the applications.

==Why SOA?==

Various businesses in the field of [http://en.wikipedia.org/wiki/Information_technology Information Technology] have to justify their projects with a return on their investments. This creates a pressure in Information Technology by making it a demanding field. Information Technology needs to have requirements in a way that it has to responsive and adapt to the changing requirements.

Information Technology companies must also be able to provide the services that are compatible with other services making it interoperable, thus creating dynamic services. Moreover, Information Technology has to face demands to bring new commercial services to a much wider array of customers. Customers may access services through web interfaces, or may be part of a supply chain that needs to decrease the time and cost of manufacturing.

Thus, Information Technology companies are always on the look out for solutions that will help them meet the above demands – without having to spend a lot of money. [http://en.wikipedia.org/wiki/Service_oriented_architecture Service Oriented Architecture] offers a solution to satisfy the above needs of the industry

==SOA-Benifits==
In architectural terms, a modern architectural design should be Service Oriented, loosely coupled, driven by events, able to support both integration and assembly, aligned with valuable life cycle support processes, and able to leverage existing infrastructure and applications.

When it comes to Service Oriented Architecture, it tends to offer a variety of different advantages over more traditional methods of distributing computing. These include
i) business services across several platforms
ii) location independence
iii) authentication as well as authorization support on different platforms
iv ) loosely coupled approach, dynamic search and connectivity to other services.

=Design Patterns in SOA=
A [http://en.wikipedia.org/wiki/Design_pattern design pattern] is a general reusable solution to a commonly occurring problem in software design. A design pattern is not a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be applied in different scenarios. Design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved.

Design patterns play a major role in SOA. The implementation and deployment of SOA designs provide different challenges during product development life cycle.Such challenges may make projects to be discontinued. Design patterns help in overcoming these problems by providing a solution to the problems posed. Each SOA design pattern provides a design solution in support of
successfully applying service orientation and establishing a quality service-oriented architecture

=Design Patterns proposed =

The proposed Design Patterns for SOA fall in to following categories. They are listed below and corresponding patterns in
each category are given. Detailed explanation of the design patterns given in the example can be found in the link provided for each category.

[http://www.soapatterns.org/masterlist_c.asp#ch6 Foundational Inventory Patterns]

These design patterns focus on providing solutions to the problems like maximizing re-composition and avoiding redundant logic.

Examples include Enterprise Inventory, Domain Inventory, Service Normalization, Logic Centralization, Service Layers Canonical Protocol, Canonical Schema

[http://www.soapatterns.org/masterlist_c.asp#ch7 Logical Inventory Layer Patterns]

These design patterns provide the solution to the problem of how can business logic be separated, reused, and governed independently?

examples for this category are Utility Abstraction,Entity Abstraction,Process Abstraction

[http://www.soapatterns.org/masterlist_c.asp#ch8 Inventory Centralization Patterns]

These patterns focus on providing solution for aspect of governing business logic etc

examples for this category are Process Centralization,Schema Centralization,Policy Centralization,Rules Centralization.

[http://www.soapatterns.org/masterlist_c.asp#ch9 Inventory Implementation Patterns]

These patterns help to solve implementation problems like limitations introduced by communication technology. Example like a single protocol may not accommodate all requirements etc

examples for this category are Dual Protocols,Canonical Resources,State Repository,Stateful Services,Service Grid,Inventory Endpoint,Cross-Domain Utility Layer

[http://www.soapatterns.org/masterlist_c.asp#ch10 Inventory Governance Patterns]

The patterns deal with the governance problems caused by service contract within the same service inventory

examples for this category are Canonical Expression,Metadata Centralization,Canonical Versioning

[http://www.soapatterns.org/masterlist_c.asp#ch11 Foundational Service Patterns]

The patterns proposed in this category focus on solving large business problems without having to build a stand alone solution.

examples for this category are Functional Decomposition,Service Encapsulation,Agnostic Context,Non-Agnostic Context,Agnostic Capability

[http://www.soapatterns.org/masterlist_c.asp#ch12 Service Implementation Patterns]

The patterns in this category focus on improving the realiability and availability of the service

examples for this category are Service Facade,Redundant Implementation,Service Data Replication,Partial State Deferral,Partial Validation,UI Mediator

[http://www.soapatterns.org/masterlist_c.asp#ch13 Service Security Patterns]

The patterns proposed in this category deal with the problem of data encapsulation and security aspects.

examples for this category are Exception Shielding,Message Screening,Trusted Subsystem ,Service Perimeter Guard

[http://www.soapatterns.org/masterlist_c.asp#ch14 Service Contract Design Patterns]

The patterns proposed in this category focus on providing solution for how to make the service contract suitable for all potential customers,make it aligned with other services etc

examples for this category are Decoupled Contract,Contract Centralization,Contract De normalization,Concurrent Contracts,Validation Abstraction

[http://www.soapatterns.org/masterlist_c.asp#ch15 Legacy Encapsulation Patterns]

The patterns proposed deals with the problems in legacy systems like processing of data contained in flat files, redundancy resulting in delivery to multiple channels etc

examples for this category are Legacy Wrapper, Multi-Channel Endpoint,File Gateway

[http://www.soapatterns.org/masterlist_c.asp#ch16 Service Governance Patterns]

These patterns provide solution for problems like updating the customers with changed service so that they are not affected, modifications in service etc

examples for this category are Compatible Change,Version Identification,Termination Notification,Service Refactoring,Service Decomposition,Proxy Capability,Decomposed Capability,Distributed Capability

[http://www.soapatterns.org/masterlist_c.asp#ch17 Capability Composition Patterns]

The pattern proposed focuses on the problem of How can a service capability solve a problem that requires logic outside of the service boundary and How can the same capability be used to help solve multiple problems?

examples for this category are Capability Composition,Capability Recomposition

[http://www.soapatterns.org/masterlist_c.asp#ch18 Service Messaging Patterns]

The patterns proposed in this category focus on setting up of message framework for transfer of data.

examples in this category are Service Messaging,Messaging Metadata,Service Agent,Intermediate Routing,State Messaging,Service Callback,Service Instance Routing,Asynchronous Queuing,Reliable Messaging,Event-Driven Messaging.

[http://www.soapatterns.org/masterlist_c.asp#ch19 Composition Implementation Patterns]

The patterns proposed in this category focus on problems during runtime like runtime activities that span multiple services fail, the parent business task is incomplete etc

examples for this category are Agnostic SubController,Composition Autonomy,Atomic Service Transaction,Compensating ServiceTransaction

[http://www.soapatterns.org/masterlist_c.asp#ch20 Service Interaction Security Patterns]

The proposed patterns in this category are focused on security methods like encryption,decryption,authenticating the data,consumer and service

examples for this category are Data Confidentiality, Data Origin Authentication, Direct Authentication, Brokered Authentication

[http://www.soapatterns.org/masterlist_c.asp#ch21 Transformation Patterns]

The Patterns proposed in this category concrete on how data from one data model can be dynamically converted to comply to a different data model.

examples for this category are Data Model Transformation,Data Format Transformation, Protocol Bridging

[http://www.soapatterns.org/masterlist_c.asp#ch22 Common Compound Design Patterns]

A compound pattern is a coarse-grained pattern comprised of a set of finer-grained patterns.

examples for this category are Orchestration,Enterprise Service Bus,Service Broker,Canonical Schema Bus,Official Endpoint,Federated Endpoint Layer,Three-Layer Inventory

=Example Design Patterns =

The following section describes five design patterns which are utilized in SOA. The described patterns provide the problem and corresponding solution.The figures for the following examples are taken from corresponding sections of [http://www.soapatterns.org/masterlist_a.asp soapatterns.org]

==Canonical protocol==

[[Image:Canonicalpattern.jpg.png]]

''Canonical Protocol Figure as given in SOA Patterns website''

Problem: Services that support different communication technologies compromise interoperability, limit the quantity of potential consumers, and introduce the need for undesirable protocol bridging measures.

Solution: The architecture establishes a single communications technology as the sole or primary medium by which services can interact.

From the above figure it is observed that the services are delivered by three different communication technologies A,B and C.These services are made to conform to one centralized communications technology, making them technologically compatible.with this these services can be delivered to consumers without much difficulty

==Dual protocol==

[[Image:dualprotocol.png]]

''Dual Protocol figure as given in SOA Pattern Official Website''

Problem: Canonical Protocol requires that all services conform to the use of the same communications technology; however, a single protocol may not be able to accommodate all service requirements, thereby introducing limitations.

Solution: The service inventory architecture is designed to support services based on primary and secondary protocols.

Regardless of protocol, all services must invoke each other via their official service contracts (A, B). Bypassing the contract may seem convenient when the underlying service logic of the primary service supports the same protocol as the secondary service (C), but it is an anti-pattern that will eventually inhibit the application of this pattern and further weaken the overall service inventory foundation.

==Protocol Bridging==

[[Image:protocolbridging.png]]

''Protocol Bridging Figure as given in the SOA Patterns Official Website''

Problem: Services using different communication protocols or different versions of the same protocol cannot exchange data.

Solution: Bridging logic is introduced to enable communication between different communication protocols by dynamically converting one protocol to another at runtime.

From the above figure it can be noticed that the consumer programs interact with a middle-tier broker that provides protocol bridging features.The consumer programs may be using different protocols like [http://java.sun.com/products/jms/ JMS] or SOAP 1.1.In order to translate the two incompatible protocols in to the required SOAP 1,2 with HTTP separate protocol adapters are used in the broker. The broker then transmits the messages to the service on behalf of the consumers.Therefore the protocol bridging is achieved.

==UI Mediator==

[[Image:uimediator.png]]

''Figure of UI Mediator as given in Official SOA Patterns Website''

Problem: Because the behavior of individual services can vary depending on their design,runtime usage, and the workload required to carry out a given capability, the consistency with which a service-oriented solution can respond to requests originating from a user-interface can fluctuate, leading to a poor user experience.

Solution: Establish mediator logic solely responsible for ensuring timely interaction and feedback with user-interfaces and presentation logic.

In this method as can be observed from the figure the three services A,B and C work behind the scenes to complete the given task.The mediator service (D) regularly updates the user interface there by hiding the underlying logic to the consumer.

==Service Facade==

[[Image:service_facade.png]]

''Figure for Service Facade as given in the official SOA Pattern Site''

Problem: The coupling of the core service logic to contracts and implementation resources can inhibit its evolution and negatively impact service consumers.

Solution: A service facade component is used to abstract a part of the service architecture with negative coupling potential.

Facade logic is placed in between the contract and the core service logic. This allows the core service logic to remain decoupled from the contract.The objective of loose coupling is achieved by this process.the core logic abstraction is obtained by this way.

=Similarities and Differences Between Patterns for SOA and Traditional pattens proposed by GoF=

The Gang of Four(Gof) comprising of Eric Gamma, Richard Helm, Ralph Johnson, and John Vlissides have documented the design patterns that were followed by Software developers and architects in object oriented space. They have documented 23 design patterns which are collectively called as Traditional design patterns.

The design patterns in SOA are similiar in some aspects to the traditional patterns.They also differ from the traditional patterns. The similiarities and differences between them are provided in this section

==Differences==

The differences between the SOA design patterns and traditional design patterns have been come up based on the individual functionality that each pattern provide. Following are the differences,

1) The [http://en.wikipedia.org/wiki/Composite_pattern composite pattern] organizes the objects in the manner to represent the part-whole hierarchies in a traditional two-tier hierarchy.

The [http://www.soapatterns.org/agnostic_subcontroller.asp agnostic sub-controller] implements the service composability but it differs from the composite pattern in such a way that cross-entity functionality is abstracted and made accessible through the sub –controller capability.

For instance, the traditional composite pattern has the object representing a part-whole hierarchy as in the below figure of graphic class which has draw(). If we require a cross-entity functionality as in the below figure, we require a colored rectangle, we require the functionality fill() of color class. Hence the sub-controller module is created which has the functionality of different parents, thus making it reusable.

''Figure to illustrate above difference''

[[Image:Composite_example.png]]

2)
The traditional [http://en.wikipedia.org/wiki/Bridge_pattern bridge pattern] separates the abstraction from its implementation in order to vary independently. Whereas the [http://www.soapatterns.org/canonical_protocol.asp canonical protocol] avoids the protocol bridging in such a way that there is a single communication technology through which the services can interact.

In the below figure of bridge pattern, the relationship between the abstraction and implementor is bridge and it results the implementor to vary independently from the abstraction by having different ConcreteImplementor. The canonical protocol avoids the variation by having a single communication technology between different objects.

''Figure to illustrate above difference''

[[Image:Traditional_bridge.png]]

''Figure for Traditional bridge pattern (Source: Elements of Reusable Object-Oriented Software by Gang of Four)''

For canonical protocol refer to the explanation given in example design patterns

3) The traditional [http://en.wikipedia.org/wiki/Builder_pattern builder pattern] decouples the construction of the object from its representation so that the same construction process can be used to develop different representations. The different representations (contracts) are addressed in SOA by the [http://www.soapatterns.org/concurrent_contracts.asp Concurrent Contracts] with the application of [http://www.soapatterns.org/service_facade.asp Service-façade] design pattern. With service-façade design pattern, an abstraction is created to support the interaction between different contracts. As a result, different contracts can be created for a single service.

In the below figure, the conversion of the text document is separated from the reader of RTF document, so that the text document can be represented in different forms like ASCIIText, TeXText and TextWidget. The different representation is achieved by decoupling of construction and abstraction. In the case of concurrent contracts pattern, the different contracts or services (invoices) are created for different consumer through service-façade by creating a new abstraction.

[[Image:Builder.png]]

''Figure for Traditional Builder pattern (Source: Elements of Reusable Object-Oriented Software by Gang of Four)''

[[Image:Concurrent_pattern.png]]

''Figure for Concurrent Contracts pattern (Source: SOA Patterns website)''

==Similarities==
1) The [http://www.soapatterns.org/service_facade.asp Service-façade] design pattern is similar to the [http://en.wikipedia.org/wiki/Facade_pattern façade] (traditional) pattern in the manner that it implements the façade logic which is creating an abstraction for intra-communication within objects to the service architecture. The advantage by adding the façade logic to the service architecture is that it preserves the underlying logic from run-time changes.

2) The [http://www.soapatterns.org/ui_mediator.asp UI Mediator] design pattern implements the [http://en.wikipedia.org/wiki/Mediator_pattern mediator] logic of traditional mediator pattern. The mediator logic aims to provide the user responses in a way that user understands, independently of what the underlying services perform.

3) The [http://www.soapatterns.org/intermediate_routing.asp Intermediate routing] pattern in SOA is similar to [http://en.wikipedia.org/wiki/Decorator_pattern Decorator pattern] (traditional) in the functionality that it adds the required logic at run-time. The decorator adds the additional functionality to the object at run-time. The intermediate routing pattern is about placing the routing logic to address the run-time scenarios.

4)The [http://www.soapatterns.org/capability_composition.asp Capability Composition] pattern in SOA implements the [http://en.wikipedia.org/wiki/Composite_pattern Composite pattern] (traditional). The Capability Composition is about composing one or more capabilities outside the service’s context to address the large, complex problem.

5) The [http://www.soapatterns.org/decoupled_contract.asp Decoupled Contract] pattern implements the traditional [http://en.wikipedia.org/wiki/Bridge_pattern Bridge pattern] in the manner that service contract is separated from the implementation. The Bridge pattern decouples the abstraction from implementation to facilitate the variation of both (abstraction and implementation).

6) The [http://www.soapatterns.org/legacy_wrapper.asp Legacy Wrapper] pattern is related to traditional [http://en.wikipedia.org/wiki/Adapter_pattern Adapter pattern]. The Legacy Wrapper pattern protects the legacy logic by providing a standard service that takes of protecting the legacy details by encapsulating, extraction or elimination. The encapsulation, extraction or elimination is done in order to change the service as the consumer requires it. This is related to adapter in a way that it converts the interface of one class to another as the client expects.

=Summary=
The various patterns in Service oriented Architecture which have been currently proposed were studied and an attempt was made to document all of them by categories.Few detailed examples are documented to get an understanding of the underlying process.Specific comparison of design patterns in SOA domain and corresponding traditional patterns has been carried out.The design patterns in SOA are still under development and many patterns are coming up due to vast technology used in this domain.

=Glossary=

1.Serive : "A service is a discoverable resource that executes a repeatable task, and is described by an externalized service specification."

2.[http://www.ibm.com/developerworks/webservices/library/ws-soa-term1/ SOA Terminology]

3.SOA :[http://en.wikipedia.org/wiki/Service-oriented_architecture Service oriented Architecture]

4.API :[http://en.wikipedia.org/wiki/Application_programming_interface Application programming interface]

5.SOAP :[http://en.wikipedia.org/wiki/SOAP Simple Object Access Protocol]

6.HTTP :[http://en.wikipedia.org/wiki/HyperText_Transfer_Protocol Hypertext Transfer Protocol]

7.GoF :[http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Gang of Four]

8.[http://soaglossary.com/ SOA Glossory]

=References=

1.[http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Design patterns for object oriented software]

2.[http://en.wikipedia.org/wiki/Service-oriented_architecture#Introduction Service Oriented Architecture]

3.[http://www.exforsys.com/tutorials/soa/soa-definitions-and-certification.html SOA Tutorial]

4.[http://www.soapatterns.org/ soa design patterns]

5.[http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29 design pattern]

6.[http://www.oracle.com/technologies/soa/center.html oracle SOA centre]

7.[http://www.ibm.com/developerworks/webservices/library/ws-soa-term1/ IBMs SOA Contributions]

8.[http://www.oracle.com/technology/pub/articles/erl_soa_design_patterns_app_sequences.html SOA Design patterns application sequences by oracle]

9.SOA Design Patterns by Thomas Erl

CSC/ECE 517 Fall 2009/wiki2 16 rs

2009-10-15T00:55:38Z

Screenit: /* Differences */

CSC/ECE 517 Fall 2009/wiki2 16 rs

SOA provides another view of providing functionality based upon services offered in terms of protocols and a specific API. Research and report on what patterns have been proposed and are utilized within this domain. How do they differ from traditional design patterns proposed by Eric Gamma, Richard Helm, Ralph Johnson, and John Vlissides? How are they similar?

----
=Introduction=

This article focuses on the design patterns which are proposed and utilized in the [http://en.wikipedia.org/wiki/Service_oriented_architecture Service Oriented Architecture]. As the SOA provides its services through the protocols and API, this article throws light on the design patterns that specifically provide services through protocols like [http://www.soapatterns.org/canonical_protocol.asp Canonical protocol], [http://www.soapatterns.org/dual_protocols.asp Dual protocols] and [http://www.soapatterns.org/protocol_bridging.asp Protocol Bridging]. In a broader perspective, other design patterns have been explained tersely. In addition to explanation of the SOA design patterns, this compares the SOA design patterns with the traditional design patterns proposed by the ‘Gang of Four’ (Eric Gamma, Richard Helm, Ralph Johnson, and John Vlissides) and comes up with the differences and similarities between them.

=Service Oriented Architecture-An Overview=

==SOA-Definition==

A [http://en.wikipedia.org/wiki/Service_oriented_architecture Service Oriented Architecture] is an architecture that provides collection of services. These services need to inter-operate with each other to provide the functionality. This architecture requires a loose coupling with operating systems and other technologies that form the basis of the application. The loose coupling between services is required because each interaction has to be independent of the other. The communication between services could be either simple data being passed or it could be either an activity coordinated between distinct entities or services. Some means of interoperability is required to provide the services in larger terms. Instead of defining the [http://en.wikipedia.org/wiki/API API], the SOA implements the interfaces using the protocols and functionality. SOA separates functions into unique entities or services, which are accessed in a network by the users to combine and reuse them to develop the applications.

==Why SOA?==

Various businesses in the field of [http://en.wikipedia.org/wiki/Information_technology Information Technology] have to justify their projects with a return on their investments. This creates a pressure in Information Technology by making it a demanding field. Information Technology needs to have requirements in a way that it has to responsive and adapt to the changing requirements.

Information Technology companies must also be able to provide the services that are compatible with other services making it interoperable, thus creating dynamic services. Moreover, Information Technology has to face demands to bring new commercial services to a much wider array of customers. Customers may access services through web interfaces, or may be part of a supply chain that needs to decrease the time and cost of manufacturing.

Thus, Information Technology companies are always on the look out for solutions that will help them meet the above demands – without having to spend a lot of money. [http://en.wikipedia.org/wiki/Service_oriented_architecture Service Oriented Architecture] offers a solution to satisfy the above needs of the industry

==SOA-Benifits==
In architectural terms, a modern architectural design should be Service Oriented, loosely coupled, driven by events, able to support both integration and assembly, aligned with valuable life cycle support processes, and able to leverage existing infrastructure and applications.

When it comes to Service Oriented Architecture, it tends to offer a variety of different advantages over more traditional methods of distributing computing. These include
i) business services across several platforms
ii) location independence
iii) authentication as well as authorization support on different platforms
iv ) loosely coupled approach, dynamic search and connectivity to other services.

=Design Patterns in SOA=
A [http://en.wikipedia.org/wiki/Design_pattern design pattern] is a general reusable solution to a commonly occurring problem in software design. A design pattern is not a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be applied in different scenarios. Design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved.

Design patterns play a major role in SOA. The implementation and deployment of SOA designs provide different challenges during product development life cycle.Such challenges may make projects to be discontinued. Design patterns help in overcoming these problems by providing a solution to the problems posed. Each SOA design pattern provides a design solution in support of
successfully applying service orientation and establishing a quality service-oriented architecture

=Design Patterns proposed =

The proposed Design Patterns for SOA fall in to following categories. They are listed below and corresponding patterns in
each category are given. Detailed explanation of the design patterns given in the example can be found in the link provided for each category.

[http://www.soapatterns.org/masterlist_c.asp#ch6 Foundational Inventory Patterns]

These design patterns focus on providing solutions to the problems like maximizing re-composition and avoiding redundant logic.

Examples include Enterprise Inventory, Domain Inventory, Service Normalization, Logic Centralization, Service Layers Canonical Protocol, Canonical Schema

[http://www.soapatterns.org/masterlist_c.asp#ch7 Logical Inventory Layer Patterns]

These design patterns provide the solution to the problem of how can business logic be separated, reused, and governed independently?

examples for this category are Utility Abstraction,Entity Abstraction,Process Abstraction

[http://www.soapatterns.org/masterlist_c.asp#ch8 Inventory Centralization Patterns]

These patterns focus on providing solution for aspect of governing business logic etc

examples for this category are Process Centralization,Schema Centralization,Policy Centralization,Rules Centralization.

[http://www.soapatterns.org/masterlist_c.asp#ch9 Inventory Implementation Patterns]

These patterns help to solve implementation problems like limitations introduced by communication technology. Example like a single protocol may not accommodate all requirements etc

examples for this category are Dual Protocols,Canonical Resources,State Repository,Stateful Services,Service Grid,Inventory Endpoint,Cross-Domain Utility Layer

[http://www.soapatterns.org/masterlist_c.asp#ch10 Inventory Governance Patterns]

The patterns deal with the governance problems caused by service contract within the same service inventory

examples for this category are Canonical Expression,Metadata Centralization,Canonical Versioning

[http://www.soapatterns.org/masterlist_c.asp#ch11 Foundational Service Patterns]

The patterns proposed in this category focus on solving large business problems without having to build a stand alone solution.

examples for this category are Functional Decomposition,Service Encapsulation,Agnostic Context,Non-Agnostic Context,Agnostic Capability

[http://www.soapatterns.org/masterlist_c.asp#ch12 Service Implementation Patterns]

The patterns in this category focus on improving the realiability and availability of the service

examples for this category are Service Facade,Redundant Implementation,Service Data Replication,Partial State Deferral,Partial Validation,UI Mediator

[http://www.soapatterns.org/masterlist_c.asp#ch13 Service Security Patterns]

The patterns proposed in this category deal with the problem of data encapsulation and security aspects.

examples for this category are Exception Shielding,Message Screening,Trusted Subsystem ,Service Perimeter Guard

[http://www.soapatterns.org/masterlist_c.asp#ch14 Service Contract Design Patterns]

The patterns proposed in this category focus on providing solution for how to make the service contract suitable for all potential customers,make it aligned with other services etc

examples for this category are Decoupled Contract,Contract Centralization,Contract De normalization,Concurrent Contracts,Validation Abstraction

[http://www.soapatterns.org/masterlist_c.asp#ch15 Legacy Encapsulation Patterns]

The patterns proposed deals with the problems in legacy systems like processing of data contained in flat files, redundancy resulting in delivery to multiple channels etc

examples for this category are Legacy Wrapper, Multi-Channel Endpoint,File Gateway

[http://www.soapatterns.org/masterlist_c.asp#ch16 Service Governance Patterns]

These patterns provide solution for problems like updating the customers with changed service so that they are not affected, modifications in service etc

examples for this category are Compatible Change,Version Identification,Termination Notification,Service Refactoring,Service Decomposition,Proxy Capability,Decomposed Capability,Distributed Capability

[http://www.soapatterns.org/masterlist_c.asp#ch17 Capability Composition Patterns]

The pattern proposed focuses on the problem of How can a service capability solve a problem that requires logic outside of the service boundary and How can the same capability be used to help solve multiple problems?

examples for this category are Capability Composition,Capability Recomposition

[http://www.soapatterns.org/masterlist_c.asp#ch18 Service Messaging Patterns]

The patterns proposed in this category focus on setting up of message framework for transfer of data.

examples in this category are Service Messaging,Messaging Metadata,Service Agent,Intermediate Routing,State Messaging,Service Callback,Service Instance Routing,Asynchronous Queuing,Reliable Messaging,Event-Driven Messaging.

[http://www.soapatterns.org/masterlist_c.asp#ch19 Composition Implementation Patterns]

The patterns proposed in this category focus on problems during runtime like runtime activities that span multiple services fail, the parent business task is incomplete etc

examples for this category are Agnostic SubController,Composition Autonomy,Atomic Service Transaction,Compensating ServiceTransaction

[http://www.soapatterns.org/masterlist_c.asp#ch20 Service Interaction Security Patterns]

The proposed patterns in this category are focused on security methods like encryption,decryption,authenticating the data,consumer and service

examples for this category are Data Confidentiality, Data Origin Authentication, Direct Authentication, Brokered Authentication

[http://www.soapatterns.org/masterlist_c.asp#ch21 Transformation Patterns]

The Patterns proposed in this category concrete on how data from one data model can be dynamically converted to comply to a different data model.

examples for this category are Data Model Transformation,Data Format Transformation, Protocol Bridging

[http://www.soapatterns.org/masterlist_c.asp#ch22 Common Compound Design Patterns]

A compound pattern is a coarse-grained pattern comprised of a set of finer-grained patterns.

examples for this category are Orchestration,Enterprise Service Bus,Service Broker,Canonical Schema Bus,Official Endpoint,Federated Endpoint Layer,Three-Layer Inventory

=Example Design Patterns =

The following section describes five design patterns which are utilized in SOA. The described patterns provide the problem and corresponding solution.The figures for the following examples are taken from corresponding sections of [http://www.soapatterns.org/masterlist_a.asp soapatterns.org]

==Canonical protocol==

[[Image:Canonicalpattern.jpg.png]]

''Canonical Protocol Figure as given in SOA Patterns website''

Problem: Services that support different communication technologies compromise interoperability, limit the quantity of potential consumers, and introduce the need for undesirable protocol bridging measures.

Solution: The architecture establishes a single communications technology as the sole or primary medium by which services can interact.

From the above figure it is observed that the services are delivered by three different communication technologies A,B and C.These services are made to conform to one centralized communications technology, making them technologically compatible.with this these services can be delivered to consumers without much difficulty

==Dual protocol==

[[Image:dualprotocol.png]]

''Dual Protocol figure as given in SOA Pattern Official Website''

Problem: Canonical Protocol requires that all services conform to the use of the same communications technology; however, a single protocol may not be able to accommodate all service requirements, thereby introducing limitations.

Solution: The service inventory architecture is designed to support services based on primary and secondary protocols.

Regardless of protocol, all services must invoke each other via their official service contracts (A, B). Bypassing the contract may seem convenient when the underlying service logic of the primary service supports the same protocol as the secondary service (C), but it is an anti-pattern that will eventually inhibit the application of this pattern and further weaken the overall service inventory foundation.

==Protocol Bridging==

[[Image:protocolbridging.png]]

''Protocol Bridging Figure as given in the SOA Patterns Official Website''

Problem: Services using different communication protocols or different versions of the same protocol cannot exchange data.

Solution: Bridging logic is introduced to enable communication between different communication protocols by dynamically converting one protocol to another at runtime.

From the above figure it can be noticed that the consumer programs interact with a middle-tier broker that provides protocol bridging features.The consumer programs may be using different protocols like [http://java.sun.com/products/jms/ JMS] or SOAP 1.1.In order to translate the two incompatible protocols in to the required SOAP 1,2 with HTTP separate protocol adapters are used in the broker. The broker then transmits the messages to the service on behalf of the consumers.Therefore the protocol bridging is achieved.

==UI Mediator==

[[Image:uimediator.png]]

''Figure of UI Mediator as given in Official SOA Patterns Website''

Problem: Because the behavior of individual services can vary depending on their design,runtime usage, and the workload required to carry out a given capability, the consistency with which a service-oriented solution can respond to requests originating from a user-interface can fluctuate, leading to a poor user experience.

Solution: Establish mediator logic solely responsible for ensuring timely interaction and feedback with user-interfaces and presentation logic.

In this method as can be observed from the figure the three services A,B and C work behind the scenes to complete the given task.The mediator service (D) regularly updates the user interface there by hiding the underlying logic to the consumer.

==Service Facade==

[[Image:service_facade.png]]

''Figure for Service Facade as given in the official SOA Pattern Site''

Problem: The coupling of the core service logic to contracts and implementation resources can inhibit its evolution and negatively impact service consumers.

Solution: A service facade component is used to abstract a part of the service architecture with negative coupling potential.

Facade logic is placed in between the contract and the core service logic. This allows the core service logic to remain decoupled from the contract.The objective of loose coupling is achieved by this process.the core logic abstraction is obtained by this way.

=Similarities and Differences Between Patterns for SOA and Traditional pattens proposed by GoF=

The Gang of Four(Gof) comprising of Eric Gamma, Richard Helm, Ralph Johnson, and John Vlissides have documented the design patterns that were followed by Software developers and architects in object oriented space. They have documented 23 design patterns which are collectively called as Traditional design patterns.

The design patterns in SOA are similiar in some aspects to the traditional patterns.They also differ from the traditional patterns. The similiarities and differences between them are provided in this section

==Differences==

The differences between the SOA design patterns and traditional design patterns have been come up based on the individual functionality that each pattern provide. Following are the differences,

1) The [http://en.wikipedia.org/wiki/Composite_pattern composite pattern] organizes the objects in the manner to represent the part-whole hierarchies in a traditional two-tier hierarchy.

The [http://www.soapatterns.org/agnostic_subcontroller.asp agnostic sub-controller] implements the service composability but it differs from the composite pattern in such a way that cross-entity functionality is abstracted and made accessible through the sub –controller capability.

For instance, the traditional composite pattern has the object representing a part-whole hierarchy as in the below figure of graphic class which has draw(). If we require a cross-entity functionality as in the below figure, we require a colored rectangle, we require the functionality fill() of color class. Hence the sub-controller module is created which has the functionality of different parents, thus making it reusable.

''Figure to illustrate above difference''

[[Image:Composite_example.png]]

2)
The traditional [http://en.wikipedia.org/wiki/Bridge_pattern bridge pattern] separates the abstraction from its implementation in order to vary independently. Whereas the [http://www.soapatterns.org/canonical_protocol.asp canonical protocol] avoids the protocol bridging in such a way that there is a single communication technology through which the services can interact.

In the below figure of bridge pattern, the relationship between the abstraction and implementor is bridge and it results the implementor to vary independently from the abstraction by having different ConcreteImplementor. The canonical protocol avoids the variation by having a single communication technology between different objects.

''Figure to illustrate above difference''

[[Image:Traditional_bridge.png]]
''Figure for Traditional bridge pattern (Source: Elements of Reusable Object-Oriented Software by Gang of Four)''

For canonical protocol refer to the explanation given in example design patterns

3) The traditional [http://en.wikipedia.org/wiki/Builder_pattern builder pattern] decouples the construction of the object from its representation so that the same construction process can be used to develop different representations. The different representations (contracts) are addressed in SOA by the [http://www.soapatterns.org/concurrent_contracts.asp Concurrent Contracts] with the application of [http://www.soapatterns.org/service_facade.asp Service-façade] design pattern. With service-façade design pattern, an abstraction is created to support the interaction between different contracts. As a result, different contracts can be created for a single service.

In the below figure, the conversion of the text document is separated from the reader of RTF document, so that the text document can be represented in different forms like ASCIIText, TeXText and TextWidget. The different representation is achieved by decoupling of construction and abstraction. In the case of concurrent contracts pattern, the different contracts or services (invoices) are created for different consumer through service-façade by creating a new abstraction.

[[Image:Builder.png]]
''Figure for Traditional Builder pattern (Source: Elements of Reusable Object-Oriented Software by Gang of Four)''

[[Image:Concurrent_pattern.png]]
Figure for Concurrent pattern

==Similarities==
1) The [http://www.soapatterns.org/service_facade.asp Service-façade] design pattern is similar to the [http://en.wikipedia.org/wiki/Facade_pattern façade] (traditional) pattern in the manner that it implements the façade logic which is creating an abstraction for intra-communication within objects to the service architecture. The advantage by adding the façade logic to the service architecture is that it preserves the underlying logic from run-time changes.

2) The [http://www.soapatterns.org/ui_mediator.asp UI Mediator] design pattern implements the [http://en.wikipedia.org/wiki/Mediator_pattern mediator] logic of traditional mediator pattern. The mediator logic aims to provide the user responses in a way that user understands, independently of what the underlying services perform.

3) The [http://www.soapatterns.org/intermediate_routing.asp Intermediate routing] pattern in SOA is similar to [http://en.wikipedia.org/wiki/Decorator_pattern Decorator pattern] (traditional) in the functionality that it adds the required logic at run-time. The decorator adds the additional functionality to the object at run-time. The intermediate routing pattern is about placing the routing logic to address the run-time scenarios.

4)The [http://www.soapatterns.org/capability_composition.asp Capability Composition] pattern in SOA implements the [http://en.wikipedia.org/wiki/Composite_pattern Composite pattern] (traditional). The Capability Composition is about composing one or more capabilities outside the service’s context to address the large, complex problem.

5) The [http://www.soapatterns.org/decoupled_contract.asp Decoupled Contract] pattern implements the traditional [http://en.wikipedia.org/wiki/Bridge_pattern Bridge pattern] in the manner that service contract is separated from the implementation. The Bridge pattern decouples the abstraction from implementation to facilitate the variation of both (abstraction and implementation).

6) The [http://www.soapatterns.org/legacy_wrapper.asp Legacy Wrapper] pattern is related to traditional [http://en.wikipedia.org/wiki/Adapter_pattern Adapter pattern]. The Legacy Wrapper pattern protects the legacy logic by providing a standard service that takes of protecting the legacy details by encapsulating, extraction or elimination. The encapsulation, extraction or elimination is done in order to change the service as the consumer requires it. This is related to adapter in a way that it converts the interface of one class to another as the client expects.

=Summary=
The various patterns in Service oriented Architecture which have been currently proposed were studied and an attempt was made to document all of them by categories.Few detailed examples are documented to get an understanding of the underlying process.Specific comparison of design patterns in SOA domain and corresponding traditional patterns has been carried out.The design patterns in SOA are still under development and many patterns are coming up due to vast technology used in this domain.

=Glossary=

1.Serive : "A service is a discoverable resource that executes a repeatable task, and is described by an externalized service specification."

2.[http://www.ibm.com/developerworks/webservices/library/ws-soa-term1/ SOA Terminology]

3.SOA :[http://en.wikipedia.org/wiki/Service-oriented_architecture Service oriented Architecture]

4.API :[http://en.wikipedia.org/wiki/Application_programming_interface Application programming interface]

5.SOAP :[http://en.wikipedia.org/wiki/SOAP Simple Object Access Protocol]

6.HTTP :[http://en.wikipedia.org/wiki/HyperText_Transfer_Protocol Hypertext Transfer Protocol]

7.GoF :[http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Gang of Four]

8.[http://soaglossary.com/ SOA Glossory]

=References=

1.[http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Design patterns for object oriented software]

2.[http://en.wikipedia.org/wiki/Service-oriented_architecture#Introduction Service Oriented Architecture]

3.[http://www.exforsys.com/tutorials/soa/soa-definitions-and-certification.html SOA Tutorial]

4.[http://www.soapatterns.org/ soa design patterns]

5.[http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29 design pattern]

6.[http://www.oracle.com/technologies/soa/center.html oracle SOA centre]

7.[http://www.ibm.com/developerworks/webservices/library/ws-soa-term1/ IBMs SOA Contributions]

8.[http://www.oracle.com/technology/pub/articles/erl_soa_design_patterns_app_sequences.html SOA Design patterns application sequences by oracle]

9.SOA Design Patterns by Thomas Erl

CSC/ECE 517 Fall 2009/wiki2 16 rs

2009-10-15T00:51:36Z

Screenit: /* Differences */

CSC/ECE 517 Fall 2009/wiki2 16 rs

SOA provides another view of providing functionality based upon services offered in terms of protocols and a specific API. Research and report on what patterns have been proposed and are utilized within this domain. How do they differ from traditional design patterns proposed by Eric Gamma, Richard Helm, Ralph Johnson, and John Vlissides? How are they similar?

----
=Introduction=

This article focuses on the design patterns which are proposed and utilized in the [http://en.wikipedia.org/wiki/Service_oriented_architecture Service Oriented Architecture]. As the SOA provides its services through the protocols and API, this article throws light on the design patterns that specifically provide services through protocols like [http://www.soapatterns.org/canonical_protocol.asp Canonical protocol], [http://www.soapatterns.org/dual_protocols.asp Dual protocols] and [http://www.soapatterns.org/protocol_bridging.asp Protocol Bridging]. In a broader perspective, other design patterns have been explained tersely. In addition to explanation of the SOA design patterns, this compares the SOA design patterns with the traditional design patterns proposed by the ‘Gang of Four’ (Eric Gamma, Richard Helm, Ralph Johnson, and John Vlissides) and comes up with the differences and similarities between them.

=Service Oriented Architecture-An Overview=

==SOA-Definition==

A [http://en.wikipedia.org/wiki/Service_oriented_architecture Service Oriented Architecture] is an architecture that provides collection of services. These services need to inter-operate with each other to provide the functionality. This architecture requires a loose coupling with operating systems and other technologies that form the basis of the application. The loose coupling between services is required because each interaction has to be independent of the other. The communication between services could be either simple data being passed or it could be either an activity coordinated between distinct entities or services. Some means of interoperability is required to provide the services in larger terms. Instead of defining the [http://en.wikipedia.org/wiki/API API], the SOA implements the interfaces using the protocols and functionality. SOA separates functions into unique entities or services, which are accessed in a network by the users to combine and reuse them to develop the applications.

==Why SOA?==

Various businesses in the field of [http://en.wikipedia.org/wiki/Information_technology Information Technology] have to justify their projects with a return on their investments. This creates a pressure in Information Technology by making it a demanding field. Information Technology needs to have requirements in a way that it has to responsive and adapt to the changing requirements.

Information Technology companies must also be able to provide the services that are compatible with other services making it interoperable, thus creating dynamic services. Moreover, Information Technology has to face demands to bring new commercial services to a much wider array of customers. Customers may access services through web interfaces, or may be part of a supply chain that needs to decrease the time and cost of manufacturing.

Thus, Information Technology companies are always on the look out for solutions that will help them meet the above demands – without having to spend a lot of money. [http://en.wikipedia.org/wiki/Service_oriented_architecture Service Oriented Architecture] offers a solution to satisfy the above needs of the industry

==SOA-Benifits==
In architectural terms, a modern architectural design should be Service Oriented, loosely coupled, driven by events, able to support both integration and assembly, aligned with valuable life cycle support processes, and able to leverage existing infrastructure and applications.

When it comes to Service Oriented Architecture, it tends to offer a variety of different advantages over more traditional methods of distributing computing. These include
i) business services across several platforms
ii) location independence
iii) authentication as well as authorization support on different platforms
iv ) loosely coupled approach, dynamic search and connectivity to other services.

=Design Patterns in SOA=
A [http://en.wikipedia.org/wiki/Design_pattern design pattern] is a general reusable solution to a commonly occurring problem in software design. A design pattern is not a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be applied in different scenarios. Design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved.

Design patterns play a major role in SOA. The implementation and deployment of SOA designs provide different challenges during product development life cycle.Such challenges may make projects to be discontinued. Design patterns help in overcoming these problems by providing a solution to the problems posed. Each SOA design pattern provides a design solution in support of
successfully applying service orientation and establishing a quality service-oriented architecture

=Design Patterns proposed =

The proposed Design Patterns for SOA fall in to following categories. They are listed below and corresponding patterns in
each category are given. Detailed explanation of the design patterns given in the example can be found in the link provided for each category.

[http://www.soapatterns.org/masterlist_c.asp#ch6 Foundational Inventory Patterns]

These design patterns focus on providing solutions to the problems like maximizing re-composition and avoiding redundant logic.

Examples include Enterprise Inventory, Domain Inventory, Service Normalization, Logic Centralization, Service Layers Canonical Protocol, Canonical Schema

[http://www.soapatterns.org/masterlist_c.asp#ch7 Logical Inventory Layer Patterns]

These design patterns provide the solution to the problem of how can business logic be separated, reused, and governed independently?

examples for this category are Utility Abstraction,Entity Abstraction,Process Abstraction

[http://www.soapatterns.org/masterlist_c.asp#ch8 Inventory Centralization Patterns]

These patterns focus on providing solution for aspect of governing business logic etc

examples for this category are Process Centralization,Schema Centralization,Policy Centralization,Rules Centralization.

[http://www.soapatterns.org/masterlist_c.asp#ch9 Inventory Implementation Patterns]

These patterns help to solve implementation problems like limitations introduced by communication technology. Example like a single protocol may not accommodate all requirements etc

examples for this category are Dual Protocols,Canonical Resources,State Repository,Stateful Services,Service Grid,Inventory Endpoint,Cross-Domain Utility Layer

[http://www.soapatterns.org/masterlist_c.asp#ch10 Inventory Governance Patterns]

The patterns deal with the governance problems caused by service contract within the same service inventory

examples for this category are Canonical Expression,Metadata Centralization,Canonical Versioning

[http://www.soapatterns.org/masterlist_c.asp#ch11 Foundational Service Patterns]

The patterns proposed in this category focus on solving large business problems without having to build a stand alone solution.

examples for this category are Functional Decomposition,Service Encapsulation,Agnostic Context,Non-Agnostic Context,Agnostic Capability

[http://www.soapatterns.org/masterlist_c.asp#ch12 Service Implementation Patterns]

The patterns in this category focus on improving the realiability and availability of the service

examples for this category are Service Facade,Redundant Implementation,Service Data Replication,Partial State Deferral,Partial Validation,UI Mediator

[http://www.soapatterns.org/masterlist_c.asp#ch13 Service Security Patterns]

The patterns proposed in this category deal with the problem of data encapsulation and security aspects.

examples for this category are Exception Shielding,Message Screening,Trusted Subsystem ,Service Perimeter Guard

[http://www.soapatterns.org/masterlist_c.asp#ch14 Service Contract Design Patterns]

The patterns proposed in this category focus on providing solution for how to make the service contract suitable for all potential customers,make it aligned with other services etc

examples for this category are Decoupled Contract,Contract Centralization,Contract De normalization,Concurrent Contracts,Validation Abstraction

[http://www.soapatterns.org/masterlist_c.asp#ch15 Legacy Encapsulation Patterns]

The patterns proposed deals with the problems in legacy systems like processing of data contained in flat files, redundancy resulting in delivery to multiple channels etc

examples for this category are Legacy Wrapper, Multi-Channel Endpoint,File Gateway

[http://www.soapatterns.org/masterlist_c.asp#ch16 Service Governance Patterns]

These patterns provide solution for problems like updating the customers with changed service so that they are not affected, modifications in service etc

examples for this category are Compatible Change,Version Identification,Termination Notification,Service Refactoring,Service Decomposition,Proxy Capability,Decomposed Capability,Distributed Capability

[http://www.soapatterns.org/masterlist_c.asp#ch17 Capability Composition Patterns]

The pattern proposed focuses on the problem of How can a service capability solve a problem that requires logic outside of the service boundary and How can the same capability be used to help solve multiple problems?

examples for this category are Capability Composition,Capability Recomposition

[http://www.soapatterns.org/masterlist_c.asp#ch18 Service Messaging Patterns]

The patterns proposed in this category focus on setting up of message framework for transfer of data.

examples in this category are Service Messaging,Messaging Metadata,Service Agent,Intermediate Routing,State Messaging,Service Callback,Service Instance Routing,Asynchronous Queuing,Reliable Messaging,Event-Driven Messaging.

[http://www.soapatterns.org/masterlist_c.asp#ch19 Composition Implementation Patterns]

The patterns proposed in this category focus on problems during runtime like runtime activities that span multiple services fail, the parent business task is incomplete etc

examples for this category are Agnostic SubController,Composition Autonomy,Atomic Service Transaction,Compensating ServiceTransaction

[http://www.soapatterns.org/masterlist_c.asp#ch20 Service Interaction Security Patterns]

The proposed patterns in this category are focused on security methods like encryption,decryption,authenticating the data,consumer and service

examples for this category are Data Confidentiality, Data Origin Authentication, Direct Authentication, Brokered Authentication

[http://www.soapatterns.org/masterlist_c.asp#ch21 Transformation Patterns]

The Patterns proposed in this category concrete on how data from one data model can be dynamically converted to comply to a different data model.

examples for this category are Data Model Transformation,Data Format Transformation, Protocol Bridging

[http://www.soapatterns.org/masterlist_c.asp#ch22 Common Compound Design Patterns]

A compound pattern is a coarse-grained pattern comprised of a set of finer-grained patterns.

examples for this category are Orchestration,Enterprise Service Bus,Service Broker,Canonical Schema Bus,Official Endpoint,Federated Endpoint Layer,Three-Layer Inventory

=Example Design Patterns =

The following section describes five design patterns which are utilized in SOA. The described patterns provide the problem and corresponding solution.The figures for the following examples are taken from corresponding sections of [http://www.soapatterns.org/masterlist_a.asp soapatterns.org]

==Canonical protocol==

[[Image:Canonicalpattern.jpg.png]]

''Canonical Protocol Figure as given in SOA Patterns website''

Problem: Services that support different communication technologies compromise interoperability, limit the quantity of potential consumers, and introduce the need for undesirable protocol bridging measures.

Solution: The architecture establishes a single communications technology as the sole or primary medium by which services can interact.

From the above figure it is observed that the services are delivered by three different communication technologies A,B and C.These services are made to conform to one centralized communications technology, making them technologically compatible.with this these services can be delivered to consumers without much difficulty

==Dual protocol==

[[Image:dualprotocol.png]]

''Dual Protocol figure as given in SOA Pattern Official Website''

Problem: Canonical Protocol requires that all services conform to the use of the same communications technology; however, a single protocol may not be able to accommodate all service requirements, thereby introducing limitations.

Solution: The service inventory architecture is designed to support services based on primary and secondary protocols.

Regardless of protocol, all services must invoke each other via their official service contracts (A, B). Bypassing the contract may seem convenient when the underlying service logic of the primary service supports the same protocol as the secondary service (C), but it is an anti-pattern that will eventually inhibit the application of this pattern and further weaken the overall service inventory foundation.

==Protocol Bridging==

[[Image:protocolbridging.png]]

''Protocol Bridging Figure as given in the SOA Patterns Official Website''

Problem: Services using different communication protocols or different versions of the same protocol cannot exchange data.

Solution: Bridging logic is introduced to enable communication between different communication protocols by dynamically converting one protocol to another at runtime.

From the above figure it can be noticed that the consumer programs interact with a middle-tier broker that provides protocol bridging features.The consumer programs may be using different protocols like [http://java.sun.com/products/jms/ JMS] or SOAP 1.1.In order to translate the two incompatible protocols in to the required SOAP 1,2 with HTTP separate protocol adapters are used in the broker. The broker then transmits the messages to the service on behalf of the consumers.Therefore the protocol bridging is achieved.

==UI Mediator==

[[Image:uimediator.png]]

''Figure of UI Mediator as given in Official SOA Patterns Website''

Problem: Because the behavior of individual services can vary depending on their design,runtime usage, and the workload required to carry out a given capability, the consistency with which a service-oriented solution can respond to requests originating from a user-interface can fluctuate, leading to a poor user experience.

Solution: Establish mediator logic solely responsible for ensuring timely interaction and feedback with user-interfaces and presentation logic.

In this method as can be observed from the figure the three services A,B and C work behind the scenes to complete the given task.The mediator service (D) regularly updates the user interface there by hiding the underlying logic to the consumer.

==Service Facade==

[[Image:service_facade.png]]

''Figure for Service Facade as given in the official SOA Pattern Site''

Problem: The coupling of the core service logic to contracts and implementation resources can inhibit its evolution and negatively impact service consumers.

Solution: A service facade component is used to abstract a part of the service architecture with negative coupling potential.

Facade logic is placed in between the contract and the core service logic. This allows the core service logic to remain decoupled from the contract.The objective of loose coupling is achieved by this process.the core logic abstraction is obtained by this way.

=Similarities and Differences Between Patterns for SOA and Traditional pattens proposed by GoF=

The Gang of Four(Gof) comprising of Eric Gamma, Richard Helm, Ralph Johnson, and John Vlissides have documented the design patterns that were followed by Software developers and architects in object oriented space. They have documented 23 design patterns which are collectively called as Traditional design patterns.

The design patterns in SOA are similiar in some aspects to the traditional patterns.They also differ from the traditional patterns. The similiarities and differences between them are provided in this section

==Differences==

The differences between the SOA design patterns and traditional design patterns have been come up based on the individual functionality that each pattern provide. Following are the differences,

1) The [http://en.wikipedia.org/wiki/Composite_pattern composite pattern] organizes the objects in the manner to represent the part-whole hierarchies in a traditional two-tier hierarchy.

The [http://www.soapatterns.org/agnostic_subcontroller.asp agnostic sub-controller] implements the service composability but it differs from the composite pattern in such a way that cross-entity functionality is abstracted and made accessible through the sub –controller capability.

For instance, the traditional composite pattern has the object representing a part-whole hierarchy as in the below figure of graphic class which has draw(). If we require a cross-entity functionality as in the below figure, we require a colored rectangle, we require the functionality fill() of color class. Hence the sub-controller module is created which has the functionality of different parents, thus making it reusable.

''Figure to illustrate above difference''

[[Image:Composite_example.png]]

2)
The traditional [http://en.wikipedia.org/wiki/Bridge_pattern bridge pattern] separates the abstraction from its implementation in order to vary independently. Whereas the [http://www.soapatterns.org/canonical_protocol.asp canonical protocol] avoids the protocol bridging in such a way that there is a single communication technology through which the services can interact.

In the below figure of bridge pattern, the relationship between the abstraction and implementor is bridge and it results the implementor to vary independently from the abstraction by having different ConcreteImplementor. The canonical protocol avoids the variation by having a single communication technology between different objects.

Figure for above difference

[[Image:Traditional_bridge.png]]
Figure for Traditional bridge pattern

For canonical protocol refer to the explanation given in example design patterns

3) The traditional [http://en.wikipedia.org/wiki/Builder_pattern builder pattern] decouples the construction of the object from its representation so that the same construction process can be used to develop different representations. The different representations (contracts) are addressed in SOA by the [http://www.soapatterns.org/concurrent_contracts.asp Concurrent Contracts] with the application of [http://www.soapatterns.org/service_facade.asp Service-façade] design pattern. With service-façade design pattern, an abstraction is created to support the interaction between different contracts. As a result, different contracts can be created for a single service.

In the below figure, the conversion of the text document is separated from the reader of RTF document, so that the text document can be represented in different forms like ASCIIText, TeXText and TextWidget. The different representation is achieved by decoupling of construction and abstraction. In the case of concurrent contracts pattern, the different contracts or services (invoices) are created for different consumer through service-façade by creating a new abstraction.

[[Image:Builder.png]]
Figure for Traditional Builder pattern

[[Image:Concurrent_pattern.png]]
Figure for Concurrent pattern

==Similarities==
1) The [http://www.soapatterns.org/service_facade.asp Service-façade] design pattern is similar to the [http://en.wikipedia.org/wiki/Facade_pattern façade] (traditional) pattern in the manner that it implements the façade logic which is creating an abstraction for intra-communication within objects to the service architecture. The advantage by adding the façade logic to the service architecture is that it preserves the underlying logic from run-time changes.

2) The [http://www.soapatterns.org/ui_mediator.asp UI Mediator] design pattern implements the [http://en.wikipedia.org/wiki/Mediator_pattern mediator] logic of traditional mediator pattern. The mediator logic aims to provide the user responses in a way that user understands, independently of what the underlying services perform.

3) The [http://www.soapatterns.org/intermediate_routing.asp Intermediate routing] pattern in SOA is similar to [http://en.wikipedia.org/wiki/Decorator_pattern Decorator pattern] (traditional) in the functionality that it adds the required logic at run-time. The decorator adds the additional functionality to the object at run-time. The intermediate routing pattern is about placing the routing logic to address the run-time scenarios.

4)The [http://www.soapatterns.org/capability_composition.asp Capability Composition] pattern in SOA implements the [http://en.wikipedia.org/wiki/Composite_pattern Composite pattern] (traditional). The Capability Composition is about composing one or more capabilities outside the service’s context to address the large, complex problem.

5) The [http://www.soapatterns.org/decoupled_contract.asp Decoupled Contract] pattern implements the traditional [http://en.wikipedia.org/wiki/Bridge_pattern Bridge pattern] in the manner that service contract is separated from the implementation. The Bridge pattern decouples the abstraction from implementation to facilitate the variation of both (abstraction and implementation).

6) The [http://www.soapatterns.org/legacy_wrapper.asp Legacy Wrapper] pattern is related to traditional [http://en.wikipedia.org/wiki/Adapter_pattern Adapter pattern]. The Legacy Wrapper pattern protects the legacy logic by providing a standard service that takes of protecting the legacy details by encapsulating, extraction or elimination. The encapsulation, extraction or elimination is done in order to change the service as the consumer requires it. This is related to adapter in a way that it converts the interface of one class to another as the client expects.

=Summary=
The various patterns in Service oriented Architecture which have been currently proposed were studied and an attempt was made to document all of them by categories.Few detailed examples are documented to get an understanding of the underlying process.Specific comparison of design patterns in SOA domain and corresponding traditional patterns has been carried out.The design patterns in SOA are still under development and many patterns are coming up due to vast technology used in this domain.

=Glossary=

1.Serive : "A service is a discoverable resource that executes a repeatable task, and is described by an externalized service specification."

2.[http://www.ibm.com/developerworks/webservices/library/ws-soa-term1/ SOA Terminology]

3.SOA :[http://en.wikipedia.org/wiki/Service-oriented_architecture Service oriented Architecture]

4.API :[http://en.wikipedia.org/wiki/Application_programming_interface Application programming interface]

5.SOAP :[http://en.wikipedia.org/wiki/SOAP Simple Object Access Protocol]

6.HTTP :[http://en.wikipedia.org/wiki/HyperText_Transfer_Protocol Hypertext Transfer Protocol]

7.GoF :[http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Gang of Four]

8.[http://soaglossary.com/ SOA Glossory]

=References=

1.[http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Design patterns for object oriented software]

2.[http://en.wikipedia.org/wiki/Service-oriented_architecture#Introduction Service Oriented Architecture]

3.[http://www.exforsys.com/tutorials/soa/soa-definitions-and-certification.html SOA Tutorial]

4.[http://www.soapatterns.org/ soa design patterns]

5.[http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29 design pattern]

6.[http://www.oracle.com/technologies/soa/center.html oracle SOA centre]

7.[http://www.ibm.com/developerworks/webservices/library/ws-soa-term1/ IBMs SOA Contributions]

8.[http://www.oracle.com/technology/pub/articles/erl_soa_design_patterns_app_sequences.html SOA Design patterns application sequences by oracle]

9.SOA Design Patterns by Thomas Erl

CSC/ECE 517 Fall 2009/wiki2 16 rs

2009-10-15T00:51:08Z

Screenit: /* Service Facade */

CSC/ECE 517 Fall 2009/wiki2 16 rs

SOA provides another view of providing functionality based upon services offered in terms of protocols and a specific API. Research and report on what patterns have been proposed and are utilized within this domain. How do they differ from traditional design patterns proposed by Eric Gamma, Richard Helm, Ralph Johnson, and John Vlissides? How are they similar?

----
=Introduction=

This article focuses on the design patterns which are proposed and utilized in the [http://en.wikipedia.org/wiki/Service_oriented_architecture Service Oriented Architecture]. As the SOA provides its services through the protocols and API, this article throws light on the design patterns that specifically provide services through protocols like [http://www.soapatterns.org/canonical_protocol.asp Canonical protocol], [http://www.soapatterns.org/dual_protocols.asp Dual protocols] and [http://www.soapatterns.org/protocol_bridging.asp Protocol Bridging]. In a broader perspective, other design patterns have been explained tersely. In addition to explanation of the SOA design patterns, this compares the SOA design patterns with the traditional design patterns proposed by the ‘Gang of Four’ (Eric Gamma, Richard Helm, Ralph Johnson, and John Vlissides) and comes up with the differences and similarities between them.

=Service Oriented Architecture-An Overview=

==SOA-Definition==

A [http://en.wikipedia.org/wiki/Service_oriented_architecture Service Oriented Architecture] is an architecture that provides collection of services. These services need to inter-operate with each other to provide the functionality. This architecture requires a loose coupling with operating systems and other technologies that form the basis of the application. The loose coupling between services is required because each interaction has to be independent of the other. The communication between services could be either simple data being passed or it could be either an activity coordinated between distinct entities or services. Some means of interoperability is required to provide the services in larger terms. Instead of defining the [http://en.wikipedia.org/wiki/API API], the SOA implements the interfaces using the protocols and functionality. SOA separates functions into unique entities or services, which are accessed in a network by the users to combine and reuse them to develop the applications.

==Why SOA?==

Various businesses in the field of [http://en.wikipedia.org/wiki/Information_technology Information Technology] have to justify their projects with a return on their investments. This creates a pressure in Information Technology by making it a demanding field. Information Technology needs to have requirements in a way that it has to responsive and adapt to the changing requirements.

Information Technology companies must also be able to provide the services that are compatible with other services making it interoperable, thus creating dynamic services. Moreover, Information Technology has to face demands to bring new commercial services to a much wider array of customers. Customers may access services through web interfaces, or may be part of a supply chain that needs to decrease the time and cost of manufacturing.

Thus, Information Technology companies are always on the look out for solutions that will help them meet the above demands – without having to spend a lot of money. [http://en.wikipedia.org/wiki/Service_oriented_architecture Service Oriented Architecture] offers a solution to satisfy the above needs of the industry

==SOA-Benifits==
In architectural terms, a modern architectural design should be Service Oriented, loosely coupled, driven by events, able to support both integration and assembly, aligned with valuable life cycle support processes, and able to leverage existing infrastructure and applications.

When it comes to Service Oriented Architecture, it tends to offer a variety of different advantages over more traditional methods of distributing computing. These include
i) business services across several platforms
ii) location independence
iii) authentication as well as authorization support on different platforms
iv ) loosely coupled approach, dynamic search and connectivity to other services.

=Design Patterns in SOA=
A [http://en.wikipedia.org/wiki/Design_pattern design pattern] is a general reusable solution to a commonly occurring problem in software design. A design pattern is not a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be applied in different scenarios. Design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved.

Design patterns play a major role in SOA. The implementation and deployment of SOA designs provide different challenges during product development life cycle.Such challenges may make projects to be discontinued. Design patterns help in overcoming these problems by providing a solution to the problems posed. Each SOA design pattern provides a design solution in support of
successfully applying service orientation and establishing a quality service-oriented architecture

=Design Patterns proposed =

The proposed Design Patterns for SOA fall in to following categories. They are listed below and corresponding patterns in
each category are given. Detailed explanation of the design patterns given in the example can be found in the link provided for each category.

[http://www.soapatterns.org/masterlist_c.asp#ch6 Foundational Inventory Patterns]

These design patterns focus on providing solutions to the problems like maximizing re-composition and avoiding redundant logic.

Examples include Enterprise Inventory, Domain Inventory, Service Normalization, Logic Centralization, Service Layers Canonical Protocol, Canonical Schema

[http://www.soapatterns.org/masterlist_c.asp#ch7 Logical Inventory Layer Patterns]

These design patterns provide the solution to the problem of how can business logic be separated, reused, and governed independently?

examples for this category are Utility Abstraction,Entity Abstraction,Process Abstraction

[http://www.soapatterns.org/masterlist_c.asp#ch8 Inventory Centralization Patterns]

These patterns focus on providing solution for aspect of governing business logic etc

examples for this category are Process Centralization,Schema Centralization,Policy Centralization,Rules Centralization.

[http://www.soapatterns.org/masterlist_c.asp#ch9 Inventory Implementation Patterns]

These patterns help to solve implementation problems like limitations introduced by communication technology. Example like a single protocol may not accommodate all requirements etc

examples for this category are Dual Protocols,Canonical Resources,State Repository,Stateful Services,Service Grid,Inventory Endpoint,Cross-Domain Utility Layer

[http://www.soapatterns.org/masterlist_c.asp#ch10 Inventory Governance Patterns]

The patterns deal with the governance problems caused by service contract within the same service inventory

examples for this category are Canonical Expression,Metadata Centralization,Canonical Versioning

[http://www.soapatterns.org/masterlist_c.asp#ch11 Foundational Service Patterns]

The patterns proposed in this category focus on solving large business problems without having to build a stand alone solution.

examples for this category are Functional Decomposition,Service Encapsulation,Agnostic Context,Non-Agnostic Context,Agnostic Capability

[http://www.soapatterns.org/masterlist_c.asp#ch12 Service Implementation Patterns]

The patterns in this category focus on improving the realiability and availability of the service

examples for this category are Service Facade,Redundant Implementation,Service Data Replication,Partial State Deferral,Partial Validation,UI Mediator

[http://www.soapatterns.org/masterlist_c.asp#ch13 Service Security Patterns]

The patterns proposed in this category deal with the problem of data encapsulation and security aspects.

examples for this category are Exception Shielding,Message Screening,Trusted Subsystem ,Service Perimeter Guard

[http://www.soapatterns.org/masterlist_c.asp#ch14 Service Contract Design Patterns]

The patterns proposed in this category focus on providing solution for how to make the service contract suitable for all potential customers,make it aligned with other services etc

examples for this category are Decoupled Contract,Contract Centralization,Contract De normalization,Concurrent Contracts,Validation Abstraction

[http://www.soapatterns.org/masterlist_c.asp#ch15 Legacy Encapsulation Patterns]

The patterns proposed deals with the problems in legacy systems like processing of data contained in flat files, redundancy resulting in delivery to multiple channels etc

examples for this category are Legacy Wrapper, Multi-Channel Endpoint,File Gateway

[http://www.soapatterns.org/masterlist_c.asp#ch16 Service Governance Patterns]

These patterns provide solution for problems like updating the customers with changed service so that they are not affected, modifications in service etc

examples for this category are Compatible Change,Version Identification,Termination Notification,Service Refactoring,Service Decomposition,Proxy Capability,Decomposed Capability,Distributed Capability

[http://www.soapatterns.org/masterlist_c.asp#ch17 Capability Composition Patterns]

The pattern proposed focuses on the problem of How can a service capability solve a problem that requires logic outside of the service boundary and How can the same capability be used to help solve multiple problems?

examples for this category are Capability Composition,Capability Recomposition

[http://www.soapatterns.org/masterlist_c.asp#ch18 Service Messaging Patterns]

The patterns proposed in this category focus on setting up of message framework for transfer of data.

examples in this category are Service Messaging,Messaging Metadata,Service Agent,Intermediate Routing,State Messaging,Service Callback,Service Instance Routing,Asynchronous Queuing,Reliable Messaging,Event-Driven Messaging.

[http://www.soapatterns.org/masterlist_c.asp#ch19 Composition Implementation Patterns]

The patterns proposed in this category focus on problems during runtime like runtime activities that span multiple services fail, the parent business task is incomplete etc

examples for this category are Agnostic SubController,Composition Autonomy,Atomic Service Transaction,Compensating ServiceTransaction

[http://www.soapatterns.org/masterlist_c.asp#ch20 Service Interaction Security Patterns]

The proposed patterns in this category are focused on security methods like encryption,decryption,authenticating the data,consumer and service

examples for this category are Data Confidentiality, Data Origin Authentication, Direct Authentication, Brokered Authentication

[http://www.soapatterns.org/masterlist_c.asp#ch21 Transformation Patterns]

The Patterns proposed in this category concrete on how data from one data model can be dynamically converted to comply to a different data model.

examples for this category are Data Model Transformation,Data Format Transformation, Protocol Bridging

[http://www.soapatterns.org/masterlist_c.asp#ch22 Common Compound Design Patterns]

A compound pattern is a coarse-grained pattern comprised of a set of finer-grained patterns.

examples for this category are Orchestration,Enterprise Service Bus,Service Broker,Canonical Schema Bus,Official Endpoint,Federated Endpoint Layer,Three-Layer Inventory

=Example Design Patterns =

The following section describes five design patterns which are utilized in SOA. The described patterns provide the problem and corresponding solution.The figures for the following examples are taken from corresponding sections of [http://www.soapatterns.org/masterlist_a.asp soapatterns.org]

==Canonical protocol==

[[Image:Canonicalpattern.jpg.png]]

''Canonical Protocol Figure as given in SOA Patterns website''

Problem: Services that support different communication technologies compromise interoperability, limit the quantity of potential consumers, and introduce the need for undesirable protocol bridging measures.

Solution: The architecture establishes a single communications technology as the sole or primary medium by which services can interact.

From the above figure it is observed that the services are delivered by three different communication technologies A,B and C.These services are made to conform to one centralized communications technology, making them technologically compatible.with this these services can be delivered to consumers without much difficulty

==Dual protocol==

[[Image:dualprotocol.png]]

''Dual Protocol figure as given in SOA Pattern Official Website''

Problem: Canonical Protocol requires that all services conform to the use of the same communications technology; however, a single protocol may not be able to accommodate all service requirements, thereby introducing limitations.

Solution: The service inventory architecture is designed to support services based on primary and secondary protocols.

Regardless of protocol, all services must invoke each other via their official service contracts (A, B). Bypassing the contract may seem convenient when the underlying service logic of the primary service supports the same protocol as the secondary service (C), but it is an anti-pattern that will eventually inhibit the application of this pattern and further weaken the overall service inventory foundation.

==Protocol Bridging==

[[Image:protocolbridging.png]]

''Protocol Bridging Figure as given in the SOA Patterns Official Website''

Problem: Services using different communication protocols or different versions of the same protocol cannot exchange data.

Solution: Bridging logic is introduced to enable communication between different communication protocols by dynamically converting one protocol to another at runtime.

From the above figure it can be noticed that the consumer programs interact with a middle-tier broker that provides protocol bridging features.The consumer programs may be using different protocols like [http://java.sun.com/products/jms/ JMS] or SOAP 1.1.In order to translate the two incompatible protocols in to the required SOAP 1,2 with HTTP separate protocol adapters are used in the broker. The broker then transmits the messages to the service on behalf of the consumers.Therefore the protocol bridging is achieved.

==UI Mediator==

[[Image:uimediator.png]]

''Figure of UI Mediator as given in Official SOA Patterns Website''

Problem: Because the behavior of individual services can vary depending on their design,runtime usage, and the workload required to carry out a given capability, the consistency with which a service-oriented solution can respond to requests originating from a user-interface can fluctuate, leading to a poor user experience.

Solution: Establish mediator logic solely responsible for ensuring timely interaction and feedback with user-interfaces and presentation logic.

In this method as can be observed from the figure the three services A,B and C work behind the scenes to complete the given task.The mediator service (D) regularly updates the user interface there by hiding the underlying logic to the consumer.

==Service Facade==

[[Image:service_facade.png]]

''Figure for Service Facade as given in the official SOA Pattern Site''

Problem: The coupling of the core service logic to contracts and implementation resources can inhibit its evolution and negatively impact service consumers.

Solution: A service facade component is used to abstract a part of the service architecture with negative coupling potential.

Facade logic is placed in between the contract and the core service logic. This allows the core service logic to remain decoupled from the contract.The objective of loose coupling is achieved by this process.the core logic abstraction is obtained by this way.

=Similarities and Differences Between Patterns for SOA and Traditional pattens proposed by GoF=

The Gang of Four(Gof) comprising of Eric Gamma, Richard Helm, Ralph Johnson, and John Vlissides have documented the design patterns that were followed by Software developers and architects in object oriented space. They have documented 23 design patterns which are collectively called as Traditional design patterns.

The design patterns in SOA are similiar in some aspects to the traditional patterns.They also differ from the traditional patterns. The similiarities and differences between them are provided in this section

==Differences==

The differences between the SOA design patterns and traditional design patterns have been come up based on the individual functionality that each pattern provide. Following are the differences,

1) The [http://en.wikipedia.org/wiki/Composite_pattern composite pattern] organizes the objects in the manner to represent the part-whole hierarchies in a traditional two-tier hierarchy.

The [http://www.soapatterns.org/agnostic_subcontroller.asp agnostic sub-controller] implements the service composability but it differs from the composite pattern in such a way that cross-entity functionality is abstracted and made accessible through the sub –controller capability.

For instance, the traditional composite pattern has the object representing a part-whole hierarchy as in the below figure of graphic class which has draw(). If we require a cross-entity functionality as in the below figure, we require a colored rectangle, we require the functionality fill() of color class. Hence the sub-controller module is created which has the functionality of different parents, thus making it reusable.

Figure to illustrate above difference

[[Image:Composite_example.png]]

2)
The traditional [http://en.wikipedia.org/wiki/Bridge_pattern bridge pattern] separates the abstraction from its implementation in order to vary independently. Whereas the [http://www.soapatterns.org/canonical_protocol.asp canonical protocol] avoids the protocol bridging in such a way that there is a single communication technology through which the services can interact.

In the below figure of bridge pattern, the relationship between the abstraction and implementor is bridge and it results the implementor to vary independently from the abstraction by having different ConcreteImplementor. The canonical protocol avoids the variation by having a single communication technology between different objects.

Figure for above difference

[[Image:Traditional_bridge.png]]
Figure for Traditional bridge pattern

For canonical protocol refer to the explanation given in example design patterns

3) The traditional [http://en.wikipedia.org/wiki/Builder_pattern builder pattern] decouples the construction of the object from its representation so that the same construction process can be used to develop different representations. The different representations (contracts) are addressed in SOA by the [http://www.soapatterns.org/concurrent_contracts.asp Concurrent Contracts] with the application of [http://www.soapatterns.org/service_facade.asp Service-façade] design pattern. With service-façade design pattern, an abstraction is created to support the interaction between different contracts. As a result, different contracts can be created for a single service.

In the below figure, the conversion of the text document is separated from the reader of RTF document, so that the text document can be represented in different forms like ASCIIText, TeXText and TextWidget. The different representation is achieved by decoupling of construction and abstraction. In the case of concurrent contracts pattern, the different contracts or services (invoices) are created for different consumer through service-façade by creating a new abstraction.

[[Image:Builder.png]]
Figure for Traditional Builder pattern

[[Image:Concurrent_pattern.png]]
Figure for Concurrent pattern

==Similarities==
1) The [http://www.soapatterns.org/service_facade.asp Service-façade] design pattern is similar to the [http://en.wikipedia.org/wiki/Facade_pattern façade] (traditional) pattern in the manner that it implements the façade logic which is creating an abstraction for intra-communication within objects to the service architecture. The advantage by adding the façade logic to the service architecture is that it preserves the underlying logic from run-time changes.

2) The [http://www.soapatterns.org/ui_mediator.asp UI Mediator] design pattern implements the [http://en.wikipedia.org/wiki/Mediator_pattern mediator] logic of traditional mediator pattern. The mediator logic aims to provide the user responses in a way that user understands, independently of what the underlying services perform.

3) The [http://www.soapatterns.org/intermediate_routing.asp Intermediate routing] pattern in SOA is similar to [http://en.wikipedia.org/wiki/Decorator_pattern Decorator pattern] (traditional) in the functionality that it adds the required logic at run-time. The decorator adds the additional functionality to the object at run-time. The intermediate routing pattern is about placing the routing logic to address the run-time scenarios.

4)The [http://www.soapatterns.org/capability_composition.asp Capability Composition] pattern in SOA implements the [http://en.wikipedia.org/wiki/Composite_pattern Composite pattern] (traditional). The Capability Composition is about composing one or more capabilities outside the service’s context to address the large, complex problem.

5) The [http://www.soapatterns.org/decoupled_contract.asp Decoupled Contract] pattern implements the traditional [http://en.wikipedia.org/wiki/Bridge_pattern Bridge pattern] in the manner that service contract is separated from the implementation. The Bridge pattern decouples the abstraction from implementation to facilitate the variation of both (abstraction and implementation).

6) The [http://www.soapatterns.org/legacy_wrapper.asp Legacy Wrapper] pattern is related to traditional [http://en.wikipedia.org/wiki/Adapter_pattern Adapter pattern]. The Legacy Wrapper pattern protects the legacy logic by providing a standard service that takes of protecting the legacy details by encapsulating, extraction or elimination. The encapsulation, extraction or elimination is done in order to change the service as the consumer requires it. This is related to adapter in a way that it converts the interface of one class to another as the client expects.

=Summary=
The various patterns in Service oriented Architecture which have been currently proposed were studied and an attempt was made to document all of them by categories.Few detailed examples are documented to get an understanding of the underlying process.Specific comparison of design patterns in SOA domain and corresponding traditional patterns has been carried out.The design patterns in SOA are still under development and many patterns are coming up due to vast technology used in this domain.

=Glossary=

1.Serive : "A service is a discoverable resource that executes a repeatable task, and is described by an externalized service specification."

2.[http://www.ibm.com/developerworks/webservices/library/ws-soa-term1/ SOA Terminology]

3.SOA :[http://en.wikipedia.org/wiki/Service-oriented_architecture Service oriented Architecture]

4.API :[http://en.wikipedia.org/wiki/Application_programming_interface Application programming interface]

5.SOAP :[http://en.wikipedia.org/wiki/SOAP Simple Object Access Protocol]

6.HTTP :[http://en.wikipedia.org/wiki/HyperText_Transfer_Protocol Hypertext Transfer Protocol]

7.GoF :[http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Gang of Four]

8.[http://soaglossary.com/ SOA Glossory]

=References=

1.[http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Design patterns for object oriented software]

2.[http://en.wikipedia.org/wiki/Service-oriented_architecture#Introduction Service Oriented Architecture]

3.[http://www.exforsys.com/tutorials/soa/soa-definitions-and-certification.html SOA Tutorial]

4.[http://www.soapatterns.org/ soa design patterns]

5.[http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29 design pattern]

6.[http://www.oracle.com/technologies/soa/center.html oracle SOA centre]

7.[http://www.ibm.com/developerworks/webservices/library/ws-soa-term1/ IBMs SOA Contributions]

8.[http://www.oracle.com/technology/pub/articles/erl_soa_design_patterns_app_sequences.html SOA Design patterns application sequences by oracle]

9.SOA Design Patterns by Thomas Erl

CSC/ECE 517 Fall 2009/wiki2 16 rs

2009-10-15T00:50:21Z

Screenit: /* UI Mediator */

CSC/ECE 517 Fall 2009/wiki2 16 rs

SOA provides another view of providing functionality based upon services offered in terms of protocols and a specific API. Research and report on what patterns have been proposed and are utilized within this domain. How do they differ from traditional design patterns proposed by Eric Gamma, Richard Helm, Ralph Johnson, and John Vlissides? How are they similar?

----
=Introduction=

This article focuses on the design patterns which are proposed and utilized in the [http://en.wikipedia.org/wiki/Service_oriented_architecture Service Oriented Architecture]. As the SOA provides its services through the protocols and API, this article throws light on the design patterns that specifically provide services through protocols like [http://www.soapatterns.org/canonical_protocol.asp Canonical protocol], [http://www.soapatterns.org/dual_protocols.asp Dual protocols] and [http://www.soapatterns.org/protocol_bridging.asp Protocol Bridging]. In a broader perspective, other design patterns have been explained tersely. In addition to explanation of the SOA design patterns, this compares the SOA design patterns with the traditional design patterns proposed by the ‘Gang of Four’ (Eric Gamma, Richard Helm, Ralph Johnson, and John Vlissides) and comes up with the differences and similarities between them.

=Service Oriented Architecture-An Overview=

==SOA-Definition==

A [http://en.wikipedia.org/wiki/Service_oriented_architecture Service Oriented Architecture] is an architecture that provides collection of services. These services need to inter-operate with each other to provide the functionality. This architecture requires a loose coupling with operating systems and other technologies that form the basis of the application. The loose coupling between services is required because each interaction has to be independent of the other. The communication between services could be either simple data being passed or it could be either an activity coordinated between distinct entities or services. Some means of interoperability is required to provide the services in larger terms. Instead of defining the [http://en.wikipedia.org/wiki/API API], the SOA implements the interfaces using the protocols and functionality. SOA separates functions into unique entities or services, which are accessed in a network by the users to combine and reuse them to develop the applications.

==Why SOA?==

Various businesses in the field of [http://en.wikipedia.org/wiki/Information_technology Information Technology] have to justify their projects with a return on their investments. This creates a pressure in Information Technology by making it a demanding field. Information Technology needs to have requirements in a way that it has to responsive and adapt to the changing requirements.

Information Technology companies must also be able to provide the services that are compatible with other services making it interoperable, thus creating dynamic services. Moreover, Information Technology has to face demands to bring new commercial services to a much wider array of customers. Customers may access services through web interfaces, or may be part of a supply chain that needs to decrease the time and cost of manufacturing.

Thus, Information Technology companies are always on the look out for solutions that will help them meet the above demands – without having to spend a lot of money. [http://en.wikipedia.org/wiki/Service_oriented_architecture Service Oriented Architecture] offers a solution to satisfy the above needs of the industry

==SOA-Benifits==
In architectural terms, a modern architectural design should be Service Oriented, loosely coupled, driven by events, able to support both integration and assembly, aligned with valuable life cycle support processes, and able to leverage existing infrastructure and applications.

When it comes to Service Oriented Architecture, it tends to offer a variety of different advantages over more traditional methods of distributing computing. These include
i) business services across several platforms
ii) location independence
iii) authentication as well as authorization support on different platforms
iv ) loosely coupled approach, dynamic search and connectivity to other services.

=Design Patterns in SOA=
A [http://en.wikipedia.org/wiki/Design_pattern design pattern] is a general reusable solution to a commonly occurring problem in software design. A design pattern is not a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be applied in different scenarios. Design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved.

Design patterns play a major role in SOA. The implementation and deployment of SOA designs provide different challenges during product development life cycle.Such challenges may make projects to be discontinued. Design patterns help in overcoming these problems by providing a solution to the problems posed. Each SOA design pattern provides a design solution in support of
successfully applying service orientation and establishing a quality service-oriented architecture

=Design Patterns proposed =

The proposed Design Patterns for SOA fall in to following categories. They are listed below and corresponding patterns in
each category are given. Detailed explanation of the design patterns given in the example can be found in the link provided for each category.

[http://www.soapatterns.org/masterlist_c.asp#ch6 Foundational Inventory Patterns]

These design patterns focus on providing solutions to the problems like maximizing re-composition and avoiding redundant logic.

Examples include Enterprise Inventory, Domain Inventory, Service Normalization, Logic Centralization, Service Layers Canonical Protocol, Canonical Schema

[http://www.soapatterns.org/masterlist_c.asp#ch7 Logical Inventory Layer Patterns]

These design patterns provide the solution to the problem of how can business logic be separated, reused, and governed independently?

examples for this category are Utility Abstraction,Entity Abstraction,Process Abstraction

[http://www.soapatterns.org/masterlist_c.asp#ch8 Inventory Centralization Patterns]

These patterns focus on providing solution for aspect of governing business logic etc

examples for this category are Process Centralization,Schema Centralization,Policy Centralization,Rules Centralization.

[http://www.soapatterns.org/masterlist_c.asp#ch9 Inventory Implementation Patterns]

These patterns help to solve implementation problems like limitations introduced by communication technology. Example like a single protocol may not accommodate all requirements etc

examples for this category are Dual Protocols,Canonical Resources,State Repository,Stateful Services,Service Grid,Inventory Endpoint,Cross-Domain Utility Layer

[http://www.soapatterns.org/masterlist_c.asp#ch10 Inventory Governance Patterns]

The patterns deal with the governance problems caused by service contract within the same service inventory

examples for this category are Canonical Expression,Metadata Centralization,Canonical Versioning

[http://www.soapatterns.org/masterlist_c.asp#ch11 Foundational Service Patterns]

The patterns proposed in this category focus on solving large business problems without having to build a stand alone solution.

examples for this category are Functional Decomposition,Service Encapsulation,Agnostic Context,Non-Agnostic Context,Agnostic Capability

[http://www.soapatterns.org/masterlist_c.asp#ch12 Service Implementation Patterns]

The patterns in this category focus on improving the realiability and availability of the service

examples for this category are Service Facade,Redundant Implementation,Service Data Replication,Partial State Deferral,Partial Validation,UI Mediator

[http://www.soapatterns.org/masterlist_c.asp#ch13 Service Security Patterns]

The patterns proposed in this category deal with the problem of data encapsulation and security aspects.

examples for this category are Exception Shielding,Message Screening,Trusted Subsystem ,Service Perimeter Guard

[http://www.soapatterns.org/masterlist_c.asp#ch14 Service Contract Design Patterns]

The patterns proposed in this category focus on providing solution for how to make the service contract suitable for all potential customers,make it aligned with other services etc

examples for this category are Decoupled Contract,Contract Centralization,Contract De normalization,Concurrent Contracts,Validation Abstraction

[http://www.soapatterns.org/masterlist_c.asp#ch15 Legacy Encapsulation Patterns]

The patterns proposed deals with the problems in legacy systems like processing of data contained in flat files, redundancy resulting in delivery to multiple channels etc

examples for this category are Legacy Wrapper, Multi-Channel Endpoint,File Gateway

[http://www.soapatterns.org/masterlist_c.asp#ch16 Service Governance Patterns]

These patterns provide solution for problems like updating the customers with changed service so that they are not affected, modifications in service etc

examples for this category are Compatible Change,Version Identification,Termination Notification,Service Refactoring,Service Decomposition,Proxy Capability,Decomposed Capability,Distributed Capability

[http://www.soapatterns.org/masterlist_c.asp#ch17 Capability Composition Patterns]

The pattern proposed focuses on the problem of How can a service capability solve a problem that requires logic outside of the service boundary and How can the same capability be used to help solve multiple problems?

examples for this category are Capability Composition,Capability Recomposition

[http://www.soapatterns.org/masterlist_c.asp#ch18 Service Messaging Patterns]

The patterns proposed in this category focus on setting up of message framework for transfer of data.

examples in this category are Service Messaging,Messaging Metadata,Service Agent,Intermediate Routing,State Messaging,Service Callback,Service Instance Routing,Asynchronous Queuing,Reliable Messaging,Event-Driven Messaging.

[http://www.soapatterns.org/masterlist_c.asp#ch19 Composition Implementation Patterns]

The patterns proposed in this category focus on problems during runtime like runtime activities that span multiple services fail, the parent business task is incomplete etc

examples for this category are Agnostic SubController,Composition Autonomy,Atomic Service Transaction,Compensating ServiceTransaction

[http://www.soapatterns.org/masterlist_c.asp#ch20 Service Interaction Security Patterns]

The proposed patterns in this category are focused on security methods like encryption,decryption,authenticating the data,consumer and service

examples for this category are Data Confidentiality, Data Origin Authentication, Direct Authentication, Brokered Authentication

[http://www.soapatterns.org/masterlist_c.asp#ch21 Transformation Patterns]

The Patterns proposed in this category concrete on how data from one data model can be dynamically converted to comply to a different data model.

examples for this category are Data Model Transformation,Data Format Transformation, Protocol Bridging

[http://www.soapatterns.org/masterlist_c.asp#ch22 Common Compound Design Patterns]

A compound pattern is a coarse-grained pattern comprised of a set of finer-grained patterns.

examples for this category are Orchestration,Enterprise Service Bus,Service Broker,Canonical Schema Bus,Official Endpoint,Federated Endpoint Layer,Three-Layer Inventory

=Example Design Patterns =

The following section describes five design patterns which are utilized in SOA. The described patterns provide the problem and corresponding solution.The figures for the following examples are taken from corresponding sections of [http://www.soapatterns.org/masterlist_a.asp soapatterns.org]

==Canonical protocol==

[[Image:Canonicalpattern.jpg.png]]

''Canonical Protocol Figure as given in SOA Patterns website''

Problem: Services that support different communication technologies compromise interoperability, limit the quantity of potential consumers, and introduce the need for undesirable protocol bridging measures.

Solution: The architecture establishes a single communications technology as the sole or primary medium by which services can interact.

From the above figure it is observed that the services are delivered by three different communication technologies A,B and C.These services are made to conform to one centralized communications technology, making them technologically compatible.with this these services can be delivered to consumers without much difficulty

==Dual protocol==

[[Image:dualprotocol.png]]

''Dual Protocol figure as given in SOA Pattern Official Website''

Problem: Canonical Protocol requires that all services conform to the use of the same communications technology; however, a single protocol may not be able to accommodate all service requirements, thereby introducing limitations.

Solution: The service inventory architecture is designed to support services based on primary and secondary protocols.

Regardless of protocol, all services must invoke each other via their official service contracts (A, B). Bypassing the contract may seem convenient when the underlying service logic of the primary service supports the same protocol as the secondary service (C), but it is an anti-pattern that will eventually inhibit the application of this pattern and further weaken the overall service inventory foundation.

==Protocol Bridging==

[[Image:protocolbridging.png]]

''Protocol Bridging Figure as given in the SOA Patterns Official Website''

Problem: Services using different communication protocols or different versions of the same protocol cannot exchange data.

Solution: Bridging logic is introduced to enable communication between different communication protocols by dynamically converting one protocol to another at runtime.

From the above figure it can be noticed that the consumer programs interact with a middle-tier broker that provides protocol bridging features.The consumer programs may be using different protocols like [http://java.sun.com/products/jms/ JMS] or SOAP 1.1.In order to translate the two incompatible protocols in to the required SOAP 1,2 with HTTP separate protocol adapters are used in the broker. The broker then transmits the messages to the service on behalf of the consumers.Therefore the protocol bridging is achieved.

==UI Mediator==

[[Image:uimediator.png]]

''Figure of UI Mediator as given in Official SOA Patterns Website''

Problem: Because the behavior of individual services can vary depending on their design,runtime usage, and the workload required to carry out a given capability, the consistency with which a service-oriented solution can respond to requests originating from a user-interface can fluctuate, leading to a poor user experience.

Solution: Establish mediator logic solely responsible for ensuring timely interaction and feedback with user-interfaces and presentation logic.

In this method as can be observed from the figure the three services A,B and C work behind the scenes to complete the given task.The mediator service (D) regularly updates the user interface there by hiding the underlying logic to the consumer.

==Service Facade==

[[Image:service_facade.png]]

Problem: The coupling of the core service logic to contracts and implementation resources can inhibit its evolution and negatively impact service consumers.

Solution: A service facade component is used to abstract a part of the service architecture with negative coupling potential.

Facade logic is placed in between the contract and the core service logic. This allows the core service logic to remain decoupled from the contract.The objective of loose coupling is achieved by this process.the core logic abstraction is obtained by this way.

=Similarities and Differences Between Patterns for SOA and Traditional pattens proposed by GoF=

The Gang of Four(Gof) comprising of Eric Gamma, Richard Helm, Ralph Johnson, and John Vlissides have documented the design patterns that were followed by Software developers and architects in object oriented space. They have documented 23 design patterns which are collectively called as Traditional design patterns.

The design patterns in SOA are similiar in some aspects to the traditional patterns.They also differ from the traditional patterns. The similiarities and differences between them are provided in this section

==Differences==

The differences between the SOA design patterns and traditional design patterns have been come up based on the individual functionality that each pattern provide. Following are the differences,

1) The [http://en.wikipedia.org/wiki/Composite_pattern composite pattern] organizes the objects in the manner to represent the part-whole hierarchies in a traditional two-tier hierarchy.

The [http://www.soapatterns.org/agnostic_subcontroller.asp agnostic sub-controller] implements the service composability but it differs from the composite pattern in such a way that cross-entity functionality is abstracted and made accessible through the sub –controller capability.

For instance, the traditional composite pattern has the object representing a part-whole hierarchy as in the below figure of graphic class which has draw(). If we require a cross-entity functionality as in the below figure, we require a colored rectangle, we require the functionality fill() of color class. Hence the sub-controller module is created which has the functionality of different parents, thus making it reusable.

Figure to illustrate above difference

[[Image:Composite_example.png]]

2)
The traditional [http://en.wikipedia.org/wiki/Bridge_pattern bridge pattern] separates the abstraction from its implementation in order to vary independently. Whereas the [http://www.soapatterns.org/canonical_protocol.asp canonical protocol] avoids the protocol bridging in such a way that there is a single communication technology through which the services can interact.

In the below figure of bridge pattern, the relationship between the abstraction and implementor is bridge and it results the implementor to vary independently from the abstraction by having different ConcreteImplementor. The canonical protocol avoids the variation by having a single communication technology between different objects.

Figure for above difference

[[Image:Traditional_bridge.png]]
Figure for Traditional bridge pattern

For canonical protocol refer to the explanation given in example design patterns

3) The traditional [http://en.wikipedia.org/wiki/Builder_pattern builder pattern] decouples the construction of the object from its representation so that the same construction process can be used to develop different representations. The different representations (contracts) are addressed in SOA by the [http://www.soapatterns.org/concurrent_contracts.asp Concurrent Contracts] with the application of [http://www.soapatterns.org/service_facade.asp Service-façade] design pattern. With service-façade design pattern, an abstraction is created to support the interaction between different contracts. As a result, different contracts can be created for a single service.

In the below figure, the conversion of the text document is separated from the reader of RTF document, so that the text document can be represented in different forms like ASCIIText, TeXText and TextWidget. The different representation is achieved by decoupling of construction and abstraction. In the case of concurrent contracts pattern, the different contracts or services (invoices) are created for different consumer through service-façade by creating a new abstraction.

[[Image:Builder.png]]
Figure for Traditional Builder pattern

[[Image:Concurrent_pattern.png]]
Figure for Concurrent pattern

==Similarities==
1) The [http://www.soapatterns.org/service_facade.asp Service-façade] design pattern is similar to the [http://en.wikipedia.org/wiki/Facade_pattern façade] (traditional) pattern in the manner that it implements the façade logic which is creating an abstraction for intra-communication within objects to the service architecture. The advantage by adding the façade logic to the service architecture is that it preserves the underlying logic from run-time changes.

2) The [http://www.soapatterns.org/ui_mediator.asp UI Mediator] design pattern implements the [http://en.wikipedia.org/wiki/Mediator_pattern mediator] logic of traditional mediator pattern. The mediator logic aims to provide the user responses in a way that user understands, independently of what the underlying services perform.

3) The [http://www.soapatterns.org/intermediate_routing.asp Intermediate routing] pattern in SOA is similar to [http://en.wikipedia.org/wiki/Decorator_pattern Decorator pattern] (traditional) in the functionality that it adds the required logic at run-time. The decorator adds the additional functionality to the object at run-time. The intermediate routing pattern is about placing the routing logic to address the run-time scenarios.

4)The [http://www.soapatterns.org/capability_composition.asp Capability Composition] pattern in SOA implements the [http://en.wikipedia.org/wiki/Composite_pattern Composite pattern] (traditional). The Capability Composition is about composing one or more capabilities outside the service’s context to address the large, complex problem.

5) The [http://www.soapatterns.org/decoupled_contract.asp Decoupled Contract] pattern implements the traditional [http://en.wikipedia.org/wiki/Bridge_pattern Bridge pattern] in the manner that service contract is separated from the implementation. The Bridge pattern decouples the abstraction from implementation to facilitate the variation of both (abstraction and implementation).

6) The [http://www.soapatterns.org/legacy_wrapper.asp Legacy Wrapper] pattern is related to traditional [http://en.wikipedia.org/wiki/Adapter_pattern Adapter pattern]. The Legacy Wrapper pattern protects the legacy logic by providing a standard service that takes of protecting the legacy details by encapsulating, extraction or elimination. The encapsulation, extraction or elimination is done in order to change the service as the consumer requires it. This is related to adapter in a way that it converts the interface of one class to another as the client expects.

=Summary=
The various patterns in Service oriented Architecture which have been currently proposed were studied and an attempt was made to document all of them by categories.Few detailed examples are documented to get an understanding of the underlying process.Specific comparison of design patterns in SOA domain and corresponding traditional patterns has been carried out.The design patterns in SOA are still under development and many patterns are coming up due to vast technology used in this domain.

=Glossary=

1.Serive : "A service is a discoverable resource that executes a repeatable task, and is described by an externalized service specification."

2.[http://www.ibm.com/developerworks/webservices/library/ws-soa-term1/ SOA Terminology]

3.SOA :[http://en.wikipedia.org/wiki/Service-oriented_architecture Service oriented Architecture]

4.API :[http://en.wikipedia.org/wiki/Application_programming_interface Application programming interface]

5.SOAP :[http://en.wikipedia.org/wiki/SOAP Simple Object Access Protocol]

6.HTTP :[http://en.wikipedia.org/wiki/HyperText_Transfer_Protocol Hypertext Transfer Protocol]

7.GoF :[http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Gang of Four]

8.[http://soaglossary.com/ SOA Glossory]

=References=

1.[http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Design patterns for object oriented software]

2.[http://en.wikipedia.org/wiki/Service-oriented_architecture#Introduction Service Oriented Architecture]

3.[http://www.exforsys.com/tutorials/soa/soa-definitions-and-certification.html SOA Tutorial]

4.[http://www.soapatterns.org/ soa design patterns]

5.[http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29 design pattern]

6.[http://www.oracle.com/technologies/soa/center.html oracle SOA centre]

7.[http://www.ibm.com/developerworks/webservices/library/ws-soa-term1/ IBMs SOA Contributions]

8.[http://www.oracle.com/technology/pub/articles/erl_soa_design_patterns_app_sequences.html SOA Design patterns application sequences by oracle]

9.SOA Design Patterns by Thomas Erl

CSC/ECE 517 Fall 2009/wiki2 16 rs

2009-10-15T00:49:04Z

Screenit: /* Protocol Bridging */

CSC/ECE 517 Fall 2009/wiki2 16 rs

SOA provides another view of providing functionality based upon services offered in terms of protocols and a specific API. Research and report on what patterns have been proposed and are utilized within this domain. How do they differ from traditional design patterns proposed by Eric Gamma, Richard Helm, Ralph Johnson, and John Vlissides? How are they similar?

----
=Introduction=

This article focuses on the design patterns which are proposed and utilized in the [http://en.wikipedia.org/wiki/Service_oriented_architecture Service Oriented Architecture]. As the SOA provides its services through the protocols and API, this article throws light on the design patterns that specifically provide services through protocols like [http://www.soapatterns.org/canonical_protocol.asp Canonical protocol], [http://www.soapatterns.org/dual_protocols.asp Dual protocols] and [http://www.soapatterns.org/protocol_bridging.asp Protocol Bridging]. In a broader perspective, other design patterns have been explained tersely. In addition to explanation of the SOA design patterns, this compares the SOA design patterns with the traditional design patterns proposed by the ‘Gang of Four’ (Eric Gamma, Richard Helm, Ralph Johnson, and John Vlissides) and comes up with the differences and similarities between them.

=Service Oriented Architecture-An Overview=

==SOA-Definition==

A [http://en.wikipedia.org/wiki/Service_oriented_architecture Service Oriented Architecture] is an architecture that provides collection of services. These services need to inter-operate with each other to provide the functionality. This architecture requires a loose coupling with operating systems and other technologies that form the basis of the application. The loose coupling between services is required because each interaction has to be independent of the other. The communication between services could be either simple data being passed or it could be either an activity coordinated between distinct entities or services. Some means of interoperability is required to provide the services in larger terms. Instead of defining the [http://en.wikipedia.org/wiki/API API], the SOA implements the interfaces using the protocols and functionality. SOA separates functions into unique entities or services, which are accessed in a network by the users to combine and reuse them to develop the applications.

==Why SOA?==

Various businesses in the field of [http://en.wikipedia.org/wiki/Information_technology Information Technology] have to justify their projects with a return on their investments. This creates a pressure in Information Technology by making it a demanding field. Information Technology needs to have requirements in a way that it has to responsive and adapt to the changing requirements.

Information Technology companies must also be able to provide the services that are compatible with other services making it interoperable, thus creating dynamic services. Moreover, Information Technology has to face demands to bring new commercial services to a much wider array of customers. Customers may access services through web interfaces, or may be part of a supply chain that needs to decrease the time and cost of manufacturing.

Thus, Information Technology companies are always on the look out for solutions that will help them meet the above demands – without having to spend a lot of money. [http://en.wikipedia.org/wiki/Service_oriented_architecture Service Oriented Architecture] offers a solution to satisfy the above needs of the industry

==SOA-Benifits==
In architectural terms, a modern architectural design should be Service Oriented, loosely coupled, driven by events, able to support both integration and assembly, aligned with valuable life cycle support processes, and able to leverage existing infrastructure and applications.

When it comes to Service Oriented Architecture, it tends to offer a variety of different advantages over more traditional methods of distributing computing. These include
i) business services across several platforms
ii) location independence
iii) authentication as well as authorization support on different platforms
iv ) loosely coupled approach, dynamic search and connectivity to other services.

=Design Patterns in SOA=
A [http://en.wikipedia.org/wiki/Design_pattern design pattern] is a general reusable solution to a commonly occurring problem in software design. A design pattern is not a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be applied in different scenarios. Design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved.

Design patterns play a major role in SOA. The implementation and deployment of SOA designs provide different challenges during product development life cycle.Such challenges may make projects to be discontinued. Design patterns help in overcoming these problems by providing a solution to the problems posed. Each SOA design pattern provides a design solution in support of
successfully applying service orientation and establishing a quality service-oriented architecture

=Design Patterns proposed =

The proposed Design Patterns for SOA fall in to following categories. They are listed below and corresponding patterns in
each category are given. Detailed explanation of the design patterns given in the example can be found in the link provided for each category.

[http://www.soapatterns.org/masterlist_c.asp#ch6 Foundational Inventory Patterns]

These design patterns focus on providing solutions to the problems like maximizing re-composition and avoiding redundant logic.

Examples include Enterprise Inventory, Domain Inventory, Service Normalization, Logic Centralization, Service Layers Canonical Protocol, Canonical Schema

[http://www.soapatterns.org/masterlist_c.asp#ch7 Logical Inventory Layer Patterns]

These design patterns provide the solution to the problem of how can business logic be separated, reused, and governed independently?

examples for this category are Utility Abstraction,Entity Abstraction,Process Abstraction

[http://www.soapatterns.org/masterlist_c.asp#ch8 Inventory Centralization Patterns]

These patterns focus on providing solution for aspect of governing business logic etc

examples for this category are Process Centralization,Schema Centralization,Policy Centralization,Rules Centralization.

[http://www.soapatterns.org/masterlist_c.asp#ch9 Inventory Implementation Patterns]

These patterns help to solve implementation problems like limitations introduced by communication technology. Example like a single protocol may not accommodate all requirements etc

examples for this category are Dual Protocols,Canonical Resources,State Repository,Stateful Services,Service Grid,Inventory Endpoint,Cross-Domain Utility Layer

[http://www.soapatterns.org/masterlist_c.asp#ch10 Inventory Governance Patterns]

The patterns deal with the governance problems caused by service contract within the same service inventory

examples for this category are Canonical Expression,Metadata Centralization,Canonical Versioning

[http://www.soapatterns.org/masterlist_c.asp#ch11 Foundational Service Patterns]

The patterns proposed in this category focus on solving large business problems without having to build a stand alone solution.

examples for this category are Functional Decomposition,Service Encapsulation,Agnostic Context,Non-Agnostic Context,Agnostic Capability

[http://www.soapatterns.org/masterlist_c.asp#ch12 Service Implementation Patterns]

The patterns in this category focus on improving the realiability and availability of the service

examples for this category are Service Facade,Redundant Implementation,Service Data Replication,Partial State Deferral,Partial Validation,UI Mediator

[http://www.soapatterns.org/masterlist_c.asp#ch13 Service Security Patterns]

The patterns proposed in this category deal with the problem of data encapsulation and security aspects.

examples for this category are Exception Shielding,Message Screening,Trusted Subsystem ,Service Perimeter Guard

[http://www.soapatterns.org/masterlist_c.asp#ch14 Service Contract Design Patterns]

The patterns proposed in this category focus on providing solution for how to make the service contract suitable for all potential customers,make it aligned with other services etc

examples for this category are Decoupled Contract,Contract Centralization,Contract De normalization,Concurrent Contracts,Validation Abstraction

[http://www.soapatterns.org/masterlist_c.asp#ch15 Legacy Encapsulation Patterns]

The patterns proposed deals with the problems in legacy systems like processing of data contained in flat files, redundancy resulting in delivery to multiple channels etc

examples for this category are Legacy Wrapper, Multi-Channel Endpoint,File Gateway

[http://www.soapatterns.org/masterlist_c.asp#ch16 Service Governance Patterns]

These patterns provide solution for problems like updating the customers with changed service so that they are not affected, modifications in service etc

examples for this category are Compatible Change,Version Identification,Termination Notification,Service Refactoring,Service Decomposition,Proxy Capability,Decomposed Capability,Distributed Capability

[http://www.soapatterns.org/masterlist_c.asp#ch17 Capability Composition Patterns]

The pattern proposed focuses on the problem of How can a service capability solve a problem that requires logic outside of the service boundary and How can the same capability be used to help solve multiple problems?

examples for this category are Capability Composition,Capability Recomposition

[http://www.soapatterns.org/masterlist_c.asp#ch18 Service Messaging Patterns]

The patterns proposed in this category focus on setting up of message framework for transfer of data.

examples in this category are Service Messaging,Messaging Metadata,Service Agent,Intermediate Routing,State Messaging,Service Callback,Service Instance Routing,Asynchronous Queuing,Reliable Messaging,Event-Driven Messaging.

[http://www.soapatterns.org/masterlist_c.asp#ch19 Composition Implementation Patterns]

The patterns proposed in this category focus on problems during runtime like runtime activities that span multiple services fail, the parent business task is incomplete etc

examples for this category are Agnostic SubController,Composition Autonomy,Atomic Service Transaction,Compensating ServiceTransaction

[http://www.soapatterns.org/masterlist_c.asp#ch20 Service Interaction Security Patterns]

The proposed patterns in this category are focused on security methods like encryption,decryption,authenticating the data,consumer and service

examples for this category are Data Confidentiality, Data Origin Authentication, Direct Authentication, Brokered Authentication

[http://www.soapatterns.org/masterlist_c.asp#ch21 Transformation Patterns]

The Patterns proposed in this category concrete on how data from one data model can be dynamically converted to comply to a different data model.

examples for this category are Data Model Transformation,Data Format Transformation, Protocol Bridging

[http://www.soapatterns.org/masterlist_c.asp#ch22 Common Compound Design Patterns]

A compound pattern is a coarse-grained pattern comprised of a set of finer-grained patterns.

examples for this category are Orchestration,Enterprise Service Bus,Service Broker,Canonical Schema Bus,Official Endpoint,Federated Endpoint Layer,Three-Layer Inventory

=Example Design Patterns =

The following section describes five design patterns which are utilized in SOA. The described patterns provide the problem and corresponding solution.The figures for the following examples are taken from corresponding sections of [http://www.soapatterns.org/masterlist_a.asp soapatterns.org]

==Canonical protocol==

[[Image:Canonicalpattern.jpg.png]]

''Canonical Protocol Figure as given in SOA Patterns website''

Problem: Services that support different communication technologies compromise interoperability, limit the quantity of potential consumers, and introduce the need for undesirable protocol bridging measures.

Solution: The architecture establishes a single communications technology as the sole or primary medium by which services can interact.

From the above figure it is observed that the services are delivered by three different communication technologies A,B and C.These services are made to conform to one centralized communications technology, making them technologically compatible.with this these services can be delivered to consumers without much difficulty

==Dual protocol==

[[Image:dualprotocol.png]]

''Dual Protocol figure as given in SOA Pattern Official Website''

Problem: Canonical Protocol requires that all services conform to the use of the same communications technology; however, a single protocol may not be able to accommodate all service requirements, thereby introducing limitations.

Solution: The service inventory architecture is designed to support services based on primary and secondary protocols.

Regardless of protocol, all services must invoke each other via their official service contracts (A, B). Bypassing the contract may seem convenient when the underlying service logic of the primary service supports the same protocol as the secondary service (C), but it is an anti-pattern that will eventually inhibit the application of this pattern and further weaken the overall service inventory foundation.

==Protocol Bridging==

[[Image:protocolbridging.png]]

''Protocol Bridging Figure as given in the SOA Patterns Official Website''

Problem: Services using different communication protocols or different versions of the same protocol cannot exchange data.

Solution: Bridging logic is introduced to enable communication between different communication protocols by dynamically converting one protocol to another at runtime.

From the above figure it can be noticed that the consumer programs interact with a middle-tier broker that provides protocol bridging features.The consumer programs may be using different protocols like [http://java.sun.com/products/jms/ JMS] or SOAP 1.1.In order to translate the two incompatible protocols in to the required SOAP 1,2 with HTTP separate protocol adapters are used in the broker. The broker then transmits the messages to the service on behalf of the consumers.Therefore the protocol bridging is achieved.

==UI Mediator==

[[Image:uimediator.png]]

Problem: Because the behavior of individual services can vary depending on their design,runtime usage, and the workload required to carry out a given capability, the consistency with which a service-oriented solution can respond to requests originating from a user-interface can fluctuate, leading to a poor user experience.

Solution: Establish mediator logic solely responsible for ensuring timely interaction and feedback with user-interfaces and presentation logic.

In this method as can be observed from the figure the three services A,B and C work behind the scenes to complete the given task.The mediator service (D) regularly updates the user interface there by hiding the underlying logic to the consumer.

==Service Facade==

[[Image:service_facade.png]]

Problem: The coupling of the core service logic to contracts and implementation resources can inhibit its evolution and negatively impact service consumers.

Solution: A service facade component is used to abstract a part of the service architecture with negative coupling potential.

Facade logic is placed in between the contract and the core service logic. This allows the core service logic to remain decoupled from the contract.The objective of loose coupling is achieved by this process.the core logic abstraction is obtained by this way.

=Similarities and Differences Between Patterns for SOA and Traditional pattens proposed by GoF=

The Gang of Four(Gof) comprising of Eric Gamma, Richard Helm, Ralph Johnson, and John Vlissides have documented the design patterns that were followed by Software developers and architects in object oriented space. They have documented 23 design patterns which are collectively called as Traditional design patterns.

The design patterns in SOA are similiar in some aspects to the traditional patterns.They also differ from the traditional patterns. The similiarities and differences between them are provided in this section

==Differences==

The differences between the SOA design patterns and traditional design patterns have been come up based on the individual functionality that each pattern provide. Following are the differences,

1) The [http://en.wikipedia.org/wiki/Composite_pattern composite pattern] organizes the objects in the manner to represent the part-whole hierarchies in a traditional two-tier hierarchy.

The [http://www.soapatterns.org/agnostic_subcontroller.asp agnostic sub-controller] implements the service composability but it differs from the composite pattern in such a way that cross-entity functionality is abstracted and made accessible through the sub –controller capability.

For instance, the traditional composite pattern has the object representing a part-whole hierarchy as in the below figure of graphic class which has draw(). If we require a cross-entity functionality as in the below figure, we require a colored rectangle, we require the functionality fill() of color class. Hence the sub-controller module is created which has the functionality of different parents, thus making it reusable.

Figure to illustrate above difference

[[Image:Composite_example.png]]

2)
The traditional [http://en.wikipedia.org/wiki/Bridge_pattern bridge pattern] separates the abstraction from its implementation in order to vary independently. Whereas the [http://www.soapatterns.org/canonical_protocol.asp canonical protocol] avoids the protocol bridging in such a way that there is a single communication technology through which the services can interact.

In the below figure of bridge pattern, the relationship between the abstraction and implementor is bridge and it results the implementor to vary independently from the abstraction by having different ConcreteImplementor. The canonical protocol avoids the variation by having a single communication technology between different objects.

Figure for above difference

[[Image:Traditional_bridge.png]]
Figure for Traditional bridge pattern

For canonical protocol refer to the explanation given in example design patterns

3) The traditional [http://en.wikipedia.org/wiki/Builder_pattern builder pattern] decouples the construction of the object from its representation so that the same construction process can be used to develop different representations. The different representations (contracts) are addressed in SOA by the [http://www.soapatterns.org/concurrent_contracts.asp Concurrent Contracts] with the application of [http://www.soapatterns.org/service_facade.asp Service-façade] design pattern. With service-façade design pattern, an abstraction is created to support the interaction between different contracts. As a result, different contracts can be created for a single service.

In the below figure, the conversion of the text document is separated from the reader of RTF document, so that the text document can be represented in different forms like ASCIIText, TeXText and TextWidget. The different representation is achieved by decoupling of construction and abstraction. In the case of concurrent contracts pattern, the different contracts or services (invoices) are created for different consumer through service-façade by creating a new abstraction.

[[Image:Builder.png]]
Figure for Traditional Builder pattern

[[Image:Concurrent_pattern.png]]
Figure for Concurrent pattern

==Similarities==
1) The [http://www.soapatterns.org/service_facade.asp Service-façade] design pattern is similar to the [http://en.wikipedia.org/wiki/Facade_pattern façade] (traditional) pattern in the manner that it implements the façade logic which is creating an abstraction for intra-communication within objects to the service architecture. The advantage by adding the façade logic to the service architecture is that it preserves the underlying logic from run-time changes.

2) The [http://www.soapatterns.org/ui_mediator.asp UI Mediator] design pattern implements the [http://en.wikipedia.org/wiki/Mediator_pattern mediator] logic of traditional mediator pattern. The mediator logic aims to provide the user responses in a way that user understands, independently of what the underlying services perform.

3) The [http://www.soapatterns.org/intermediate_routing.asp Intermediate routing] pattern in SOA is similar to [http://en.wikipedia.org/wiki/Decorator_pattern Decorator pattern] (traditional) in the functionality that it adds the required logic at run-time. The decorator adds the additional functionality to the object at run-time. The intermediate routing pattern is about placing the routing logic to address the run-time scenarios.

4)The [http://www.soapatterns.org/capability_composition.asp Capability Composition] pattern in SOA implements the [http://en.wikipedia.org/wiki/Composite_pattern Composite pattern] (traditional). The Capability Composition is about composing one or more capabilities outside the service’s context to address the large, complex problem.

5) The [http://www.soapatterns.org/decoupled_contract.asp Decoupled Contract] pattern implements the traditional [http://en.wikipedia.org/wiki/Bridge_pattern Bridge pattern] in the manner that service contract is separated from the implementation. The Bridge pattern decouples the abstraction from implementation to facilitate the variation of both (abstraction and implementation).

6) The [http://www.soapatterns.org/legacy_wrapper.asp Legacy Wrapper] pattern is related to traditional [http://en.wikipedia.org/wiki/Adapter_pattern Adapter pattern]. The Legacy Wrapper pattern protects the legacy logic by providing a standard service that takes of protecting the legacy details by encapsulating, extraction or elimination. The encapsulation, extraction or elimination is done in order to change the service as the consumer requires it. This is related to adapter in a way that it converts the interface of one class to another as the client expects.

=Summary=
The various patterns in Service oriented Architecture which have been currently proposed were studied and an attempt was made to document all of them by categories.Few detailed examples are documented to get an understanding of the underlying process.Specific comparison of design patterns in SOA domain and corresponding traditional patterns has been carried out.The design patterns in SOA are still under development and many patterns are coming up due to vast technology used in this domain.

=Glossary=

1.Serive : "A service is a discoverable resource that executes a repeatable task, and is described by an externalized service specification."

2.[http://www.ibm.com/developerworks/webservices/library/ws-soa-term1/ SOA Terminology]

3.SOA :[http://en.wikipedia.org/wiki/Service-oriented_architecture Service oriented Architecture]

4.API :[http://en.wikipedia.org/wiki/Application_programming_interface Application programming interface]

5.SOAP :[http://en.wikipedia.org/wiki/SOAP Simple Object Access Protocol]

6.HTTP :[http://en.wikipedia.org/wiki/HyperText_Transfer_Protocol Hypertext Transfer Protocol]

7.GoF :[http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Gang of Four]

8.[http://soaglossary.com/ SOA Glossory]

=References=

1.[http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Design patterns for object oriented software]

2.[http://en.wikipedia.org/wiki/Service-oriented_architecture#Introduction Service Oriented Architecture]

3.[http://www.exforsys.com/tutorials/soa/soa-definitions-and-certification.html SOA Tutorial]

4.[http://www.soapatterns.org/ soa design patterns]

5.[http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29 design pattern]

6.[http://www.oracle.com/technologies/soa/center.html oracle SOA centre]

7.[http://www.ibm.com/developerworks/webservices/library/ws-soa-term1/ IBMs SOA Contributions]

8.[http://www.oracle.com/technology/pub/articles/erl_soa_design_patterns_app_sequences.html SOA Design patterns application sequences by oracle]

9.SOA Design Patterns by Thomas Erl

CSC/ECE 517 Fall 2009/wiki2 16 rs

2009-10-15T00:47:41Z

Screenit: /* Dual protocol */

CSC/ECE 517 Fall 2009/wiki2 16 rs

SOA provides another view of providing functionality based upon services offered in terms of protocols and a specific API. Research and report on what patterns have been proposed and are utilized within this domain. How do they differ from traditional design patterns proposed by Eric Gamma, Richard Helm, Ralph Johnson, and John Vlissides? How are they similar?

----
=Introduction=

This article focuses on the design patterns which are proposed and utilized in the [http://en.wikipedia.org/wiki/Service_oriented_architecture Service Oriented Architecture]. As the SOA provides its services through the protocols and API, this article throws light on the design patterns that specifically provide services through protocols like [http://www.soapatterns.org/canonical_protocol.asp Canonical protocol], [http://www.soapatterns.org/dual_protocols.asp Dual protocols] and [http://www.soapatterns.org/protocol_bridging.asp Protocol Bridging]. In a broader perspective, other design patterns have been explained tersely. In addition to explanation of the SOA design patterns, this compares the SOA design patterns with the traditional design patterns proposed by the ‘Gang of Four’ (Eric Gamma, Richard Helm, Ralph Johnson, and John Vlissides) and comes up with the differences and similarities between them.

=Service Oriented Architecture-An Overview=

==SOA-Definition==

A [http://en.wikipedia.org/wiki/Service_oriented_architecture Service Oriented Architecture] is an architecture that provides collection of services. These services need to inter-operate with each other to provide the functionality. This architecture requires a loose coupling with operating systems and other technologies that form the basis of the application. The loose coupling between services is required because each interaction has to be independent of the other. The communication between services could be either simple data being passed or it could be either an activity coordinated between distinct entities or services. Some means of interoperability is required to provide the services in larger terms. Instead of defining the [http://en.wikipedia.org/wiki/API API], the SOA implements the interfaces using the protocols and functionality. SOA separates functions into unique entities or services, which are accessed in a network by the users to combine and reuse them to develop the applications.

==Why SOA?==

Various businesses in the field of [http://en.wikipedia.org/wiki/Information_technology Information Technology] have to justify their projects with a return on their investments. This creates a pressure in Information Technology by making it a demanding field. Information Technology needs to have requirements in a way that it has to responsive and adapt to the changing requirements.

Information Technology companies must also be able to provide the services that are compatible with other services making it interoperable, thus creating dynamic services. Moreover, Information Technology has to face demands to bring new commercial services to a much wider array of customers. Customers may access services through web interfaces, or may be part of a supply chain that needs to decrease the time and cost of manufacturing.

Thus, Information Technology companies are always on the look out for solutions that will help them meet the above demands – without having to spend a lot of money. [http://en.wikipedia.org/wiki/Service_oriented_architecture Service Oriented Architecture] offers a solution to satisfy the above needs of the industry

==SOA-Benifits==
In architectural terms, a modern architectural design should be Service Oriented, loosely coupled, driven by events, able to support both integration and assembly, aligned with valuable life cycle support processes, and able to leverage existing infrastructure and applications.

When it comes to Service Oriented Architecture, it tends to offer a variety of different advantages over more traditional methods of distributing computing. These include
i) business services across several platforms
ii) location independence
iii) authentication as well as authorization support on different platforms
iv ) loosely coupled approach, dynamic search and connectivity to other services.

=Design Patterns in SOA=
A [http://en.wikipedia.org/wiki/Design_pattern design pattern] is a general reusable solution to a commonly occurring problem in software design. A design pattern is not a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be applied in different scenarios. Design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved.

Design patterns play a major role in SOA. The implementation and deployment of SOA designs provide different challenges during product development life cycle.Such challenges may make projects to be discontinued. Design patterns help in overcoming these problems by providing a solution to the problems posed. Each SOA design pattern provides a design solution in support of
successfully applying service orientation and establishing a quality service-oriented architecture

=Design Patterns proposed =

The proposed Design Patterns for SOA fall in to following categories. They are listed below and corresponding patterns in
each category are given. Detailed explanation of the design patterns given in the example can be found in the link provided for each category.

[http://www.soapatterns.org/masterlist_c.asp#ch6 Foundational Inventory Patterns]

These design patterns focus on providing solutions to the problems like maximizing re-composition and avoiding redundant logic.

Examples include Enterprise Inventory, Domain Inventory, Service Normalization, Logic Centralization, Service Layers Canonical Protocol, Canonical Schema

[http://www.soapatterns.org/masterlist_c.asp#ch7 Logical Inventory Layer Patterns]

These design patterns provide the solution to the problem of how can business logic be separated, reused, and governed independently?

examples for this category are Utility Abstraction,Entity Abstraction,Process Abstraction

[http://www.soapatterns.org/masterlist_c.asp#ch8 Inventory Centralization Patterns]

These patterns focus on providing solution for aspect of governing business logic etc

examples for this category are Process Centralization,Schema Centralization,Policy Centralization,Rules Centralization.

[http://www.soapatterns.org/masterlist_c.asp#ch9 Inventory Implementation Patterns]

These patterns help to solve implementation problems like limitations introduced by communication technology. Example like a single protocol may not accommodate all requirements etc

examples for this category are Dual Protocols,Canonical Resources,State Repository,Stateful Services,Service Grid,Inventory Endpoint,Cross-Domain Utility Layer

[http://www.soapatterns.org/masterlist_c.asp#ch10 Inventory Governance Patterns]

The patterns deal with the governance problems caused by service contract within the same service inventory

examples for this category are Canonical Expression,Metadata Centralization,Canonical Versioning

[http://www.soapatterns.org/masterlist_c.asp#ch11 Foundational Service Patterns]

The patterns proposed in this category focus on solving large business problems without having to build a stand alone solution.

examples for this category are Functional Decomposition,Service Encapsulation,Agnostic Context,Non-Agnostic Context,Agnostic Capability

[http://www.soapatterns.org/masterlist_c.asp#ch12 Service Implementation Patterns]

The patterns in this category focus on improving the realiability and availability of the service

examples for this category are Service Facade,Redundant Implementation,Service Data Replication,Partial State Deferral,Partial Validation,UI Mediator

[http://www.soapatterns.org/masterlist_c.asp#ch13 Service Security Patterns]

The patterns proposed in this category deal with the problem of data encapsulation and security aspects.

examples for this category are Exception Shielding,Message Screening,Trusted Subsystem ,Service Perimeter Guard

[http://www.soapatterns.org/masterlist_c.asp#ch14 Service Contract Design Patterns]

The patterns proposed in this category focus on providing solution for how to make the service contract suitable for all potential customers,make it aligned with other services etc

examples for this category are Decoupled Contract,Contract Centralization,Contract De normalization,Concurrent Contracts,Validation Abstraction

[http://www.soapatterns.org/masterlist_c.asp#ch15 Legacy Encapsulation Patterns]

The patterns proposed deals with the problems in legacy systems like processing of data contained in flat files, redundancy resulting in delivery to multiple channels etc

examples for this category are Legacy Wrapper, Multi-Channel Endpoint,File Gateway

[http://www.soapatterns.org/masterlist_c.asp#ch16 Service Governance Patterns]

These patterns provide solution for problems like updating the customers with changed service so that they are not affected, modifications in service etc

examples for this category are Compatible Change,Version Identification,Termination Notification,Service Refactoring,Service Decomposition,Proxy Capability,Decomposed Capability,Distributed Capability

[http://www.soapatterns.org/masterlist_c.asp#ch17 Capability Composition Patterns]

The pattern proposed focuses on the problem of How can a service capability solve a problem that requires logic outside of the service boundary and How can the same capability be used to help solve multiple problems?

examples for this category are Capability Composition,Capability Recomposition

[http://www.soapatterns.org/masterlist_c.asp#ch18 Service Messaging Patterns]

The patterns proposed in this category focus on setting up of message framework for transfer of data.

examples in this category are Service Messaging,Messaging Metadata,Service Agent,Intermediate Routing,State Messaging,Service Callback,Service Instance Routing,Asynchronous Queuing,Reliable Messaging,Event-Driven Messaging.

[http://www.soapatterns.org/masterlist_c.asp#ch19 Composition Implementation Patterns]

The patterns proposed in this category focus on problems during runtime like runtime activities that span multiple services fail, the parent business task is incomplete etc

examples for this category are Agnostic SubController,Composition Autonomy,Atomic Service Transaction,Compensating ServiceTransaction

[http://www.soapatterns.org/masterlist_c.asp#ch20 Service Interaction Security Patterns]

The proposed patterns in this category are focused on security methods like encryption,decryption,authenticating the data,consumer and service

examples for this category are Data Confidentiality, Data Origin Authentication, Direct Authentication, Brokered Authentication

[http://www.soapatterns.org/masterlist_c.asp#ch21 Transformation Patterns]

The Patterns proposed in this category concrete on how data from one data model can be dynamically converted to comply to a different data model.

examples for this category are Data Model Transformation,Data Format Transformation, Protocol Bridging

[http://www.soapatterns.org/masterlist_c.asp#ch22 Common Compound Design Patterns]

A compound pattern is a coarse-grained pattern comprised of a set of finer-grained patterns.

examples for this category are Orchestration,Enterprise Service Bus,Service Broker,Canonical Schema Bus,Official Endpoint,Federated Endpoint Layer,Three-Layer Inventory

=Example Design Patterns =

The following section describes five design patterns which are utilized in SOA. The described patterns provide the problem and corresponding solution.The figures for the following examples are taken from corresponding sections of [http://www.soapatterns.org/masterlist_a.asp soapatterns.org]

==Canonical protocol==

[[Image:Canonicalpattern.jpg.png]]

''Canonical Protocol Figure as given in SOA Patterns website''

Problem: Services that support different communication technologies compromise interoperability, limit the quantity of potential consumers, and introduce the need for undesirable protocol bridging measures.

Solution: The architecture establishes a single communications technology as the sole or primary medium by which services can interact.

From the above figure it is observed that the services are delivered by three different communication technologies A,B and C.These services are made to conform to one centralized communications technology, making them technologically compatible.with this these services can be delivered to consumers without much difficulty

==Dual protocol==

[[Image:dualprotocol.png]]

''Dual Protocol figure as given in SOA Pattern Official Website''

Problem: Canonical Protocol requires that all services conform to the use of the same communications technology; however, a single protocol may not be able to accommodate all service requirements, thereby introducing limitations.

Solution: The service inventory architecture is designed to support services based on primary and secondary protocols.

Regardless of protocol, all services must invoke each other via their official service contracts (A, B). Bypassing the contract may seem convenient when the underlying service logic of the primary service supports the same protocol as the secondary service (C), but it is an anti-pattern that will eventually inhibit the application of this pattern and further weaken the overall service inventory foundation.

==Protocol Bridging==

[[Image:protocolbridging.png]]

Problem: Services using different communication protocols or different versions of the same protocol cannot exchange data.

Solution: Bridging logic is introduced to enable communication between different communication protocols by dynamically converting one protocol to another at runtime.

From the above figure it can be noticed that the consumer programs interact with a middle-tier broker that provides protocol bridging features.The consumer programs may be using different protocols like [http://java.sun.com/products/jms/ JMS] or SOAP 1.1.In order to translate the two incompatible protocols in to the required SOAP 1,2 with HTTP separate protocol adapters are used in the broker. The broker then transmits the messages to the service on behalf of the consumers.Therefore the protocol bridging is achieved.

==UI Mediator==

[[Image:uimediator.png]]

Problem: Because the behavior of individual services can vary depending on their design,runtime usage, and the workload required to carry out a given capability, the consistency with which a service-oriented solution can respond to requests originating from a user-interface can fluctuate, leading to a poor user experience.

Solution: Establish mediator logic solely responsible for ensuring timely interaction and feedback with user-interfaces and presentation logic.

In this method as can be observed from the figure the three services A,B and C work behind the scenes to complete the given task.The mediator service (D) regularly updates the user interface there by hiding the underlying logic to the consumer.

==Service Facade==

[[Image:service_facade.png]]

Problem: The coupling of the core service logic to contracts and implementation resources can inhibit its evolution and negatively impact service consumers.

Solution: A service facade component is used to abstract a part of the service architecture with negative coupling potential.

Facade logic is placed in between the contract and the core service logic. This allows the core service logic to remain decoupled from the contract.The objective of loose coupling is achieved by this process.the core logic abstraction is obtained by this way.

=Similarities and Differences Between Patterns for SOA and Traditional pattens proposed by GoF=

The Gang of Four(Gof) comprising of Eric Gamma, Richard Helm, Ralph Johnson, and John Vlissides have documented the design patterns that were followed by Software developers and architects in object oriented space. They have documented 23 design patterns which are collectively called as Traditional design patterns.

The design patterns in SOA are similiar in some aspects to the traditional patterns.They also differ from the traditional patterns. The similiarities and differences between them are provided in this section

==Differences==

The differences between the SOA design patterns and traditional design patterns have been come up based on the individual functionality that each pattern provide. Following are the differences,

1) The [http://en.wikipedia.org/wiki/Composite_pattern composite pattern] organizes the objects in the manner to represent the part-whole hierarchies in a traditional two-tier hierarchy.

The [http://www.soapatterns.org/agnostic_subcontroller.asp agnostic sub-controller] implements the service composability but it differs from the composite pattern in such a way that cross-entity functionality is abstracted and made accessible through the sub –controller capability.

For instance, the traditional composite pattern has the object representing a part-whole hierarchy as in the below figure of graphic class which has draw(). If we require a cross-entity functionality as in the below figure, we require a colored rectangle, we require the functionality fill() of color class. Hence the sub-controller module is created which has the functionality of different parents, thus making it reusable.

Figure to illustrate above difference

[[Image:Composite_example.png]]

2)
The traditional [http://en.wikipedia.org/wiki/Bridge_pattern bridge pattern] separates the abstraction from its implementation in order to vary independently. Whereas the [http://www.soapatterns.org/canonical_protocol.asp canonical protocol] avoids the protocol bridging in such a way that there is a single communication technology through which the services can interact.

In the below figure of bridge pattern, the relationship between the abstraction and implementor is bridge and it results the implementor to vary independently from the abstraction by having different ConcreteImplementor. The canonical protocol avoids the variation by having a single communication technology between different objects.

Figure for above difference

[[Image:Traditional_bridge.png]]
Figure for Traditional bridge pattern

For canonical protocol refer to the explanation given in example design patterns

3) The traditional [http://en.wikipedia.org/wiki/Builder_pattern builder pattern] decouples the construction of the object from its representation so that the same construction process can be used to develop different representations. The different representations (contracts) are addressed in SOA by the [http://www.soapatterns.org/concurrent_contracts.asp Concurrent Contracts] with the application of [http://www.soapatterns.org/service_facade.asp Service-façade] design pattern. With service-façade design pattern, an abstraction is created to support the interaction between different contracts. As a result, different contracts can be created for a single service.

In the below figure, the conversion of the text document is separated from the reader of RTF document, so that the text document can be represented in different forms like ASCIIText, TeXText and TextWidget. The different representation is achieved by decoupling of construction and abstraction. In the case of concurrent contracts pattern, the different contracts or services (invoices) are created for different consumer through service-façade by creating a new abstraction.

[[Image:Builder.png]]
Figure for Traditional Builder pattern

[[Image:Concurrent_pattern.png]]
Figure for Concurrent pattern

==Similarities==
1) The [http://www.soapatterns.org/service_facade.asp Service-façade] design pattern is similar to the [http://en.wikipedia.org/wiki/Facade_pattern façade] (traditional) pattern in the manner that it implements the façade logic which is creating an abstraction for intra-communication within objects to the service architecture. The advantage by adding the façade logic to the service architecture is that it preserves the underlying logic from run-time changes.

2) The [http://www.soapatterns.org/ui_mediator.asp UI Mediator] design pattern implements the [http://en.wikipedia.org/wiki/Mediator_pattern mediator] logic of traditional mediator pattern. The mediator logic aims to provide the user responses in a way that user understands, independently of what the underlying services perform.

3) The [http://www.soapatterns.org/intermediate_routing.asp Intermediate routing] pattern in SOA is similar to [http://en.wikipedia.org/wiki/Decorator_pattern Decorator pattern] (traditional) in the functionality that it adds the required logic at run-time. The decorator adds the additional functionality to the object at run-time. The intermediate routing pattern is about placing the routing logic to address the run-time scenarios.

4)The [http://www.soapatterns.org/capability_composition.asp Capability Composition] pattern in SOA implements the [http://en.wikipedia.org/wiki/Composite_pattern Composite pattern] (traditional). The Capability Composition is about composing one or more capabilities outside the service’s context to address the large, complex problem.

5) The [http://www.soapatterns.org/decoupled_contract.asp Decoupled Contract] pattern implements the traditional [http://en.wikipedia.org/wiki/Bridge_pattern Bridge pattern] in the manner that service contract is separated from the implementation. The Bridge pattern decouples the abstraction from implementation to facilitate the variation of both (abstraction and implementation).

6) The [http://www.soapatterns.org/legacy_wrapper.asp Legacy Wrapper] pattern is related to traditional [http://en.wikipedia.org/wiki/Adapter_pattern Adapter pattern]. The Legacy Wrapper pattern protects the legacy logic by providing a standard service that takes of protecting the legacy details by encapsulating, extraction or elimination. The encapsulation, extraction or elimination is done in order to change the service as the consumer requires it. This is related to adapter in a way that it converts the interface of one class to another as the client expects.

=Summary=
The various patterns in Service oriented Architecture which have been currently proposed were studied and an attempt was made to document all of them by categories.Few detailed examples are documented to get an understanding of the underlying process.Specific comparison of design patterns in SOA domain and corresponding traditional patterns has been carried out.The design patterns in SOA are still under development and many patterns are coming up due to vast technology used in this domain.

=Glossary=

1.Serive : "A service is a discoverable resource that executes a repeatable task, and is described by an externalized service specification."

2.[http://www.ibm.com/developerworks/webservices/library/ws-soa-term1/ SOA Terminology]

3.SOA :[http://en.wikipedia.org/wiki/Service-oriented_architecture Service oriented Architecture]

4.API :[http://en.wikipedia.org/wiki/Application_programming_interface Application programming interface]

5.SOAP :[http://en.wikipedia.org/wiki/SOAP Simple Object Access Protocol]

6.HTTP :[http://en.wikipedia.org/wiki/HyperText_Transfer_Protocol Hypertext Transfer Protocol]

7.GoF :[http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Gang of Four]

8.[http://soaglossary.com/ SOA Glossory]

=References=

1.[http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Design patterns for object oriented software]

2.[http://en.wikipedia.org/wiki/Service-oriented_architecture#Introduction Service Oriented Architecture]

3.[http://www.exforsys.com/tutorials/soa/soa-definitions-and-certification.html SOA Tutorial]

4.[http://www.soapatterns.org/ soa design patterns]

5.[http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29 design pattern]

6.[http://www.oracle.com/technologies/soa/center.html oracle SOA centre]

7.[http://www.ibm.com/developerworks/webservices/library/ws-soa-term1/ IBMs SOA Contributions]

8.[http://www.oracle.com/technology/pub/articles/erl_soa_design_patterns_app_sequences.html SOA Design patterns application sequences by oracle]

9.SOA Design Patterns by Thomas Erl

CSC/ECE 517 Fall 2009/wiki2 16 rs

2009-10-15T00:46:37Z

Screenit: /* Canonical protocol */

CSC/ECE 517 Fall 2009/wiki2 16 rs

SOA provides another view of providing functionality based upon services offered in terms of protocols and a specific API. Research and report on what patterns have been proposed and are utilized within this domain. How do they differ from traditional design patterns proposed by Eric Gamma, Richard Helm, Ralph Johnson, and John Vlissides? How are they similar?

----
=Introduction=

This article focuses on the design patterns which are proposed and utilized in the [http://en.wikipedia.org/wiki/Service_oriented_architecture Service Oriented Architecture]. As the SOA provides its services through the protocols and API, this article throws light on the design patterns that specifically provide services through protocols like [http://www.soapatterns.org/canonical_protocol.asp Canonical protocol], [http://www.soapatterns.org/dual_protocols.asp Dual protocols] and [http://www.soapatterns.org/protocol_bridging.asp Protocol Bridging]. In a broader perspective, other design patterns have been explained tersely. In addition to explanation of the SOA design patterns, this compares the SOA design patterns with the traditional design patterns proposed by the ‘Gang of Four’ (Eric Gamma, Richard Helm, Ralph Johnson, and John Vlissides) and comes up with the differences and similarities between them.

=Service Oriented Architecture-An Overview=

==SOA-Definition==

A [http://en.wikipedia.org/wiki/Service_oriented_architecture Service Oriented Architecture] is an architecture that provides collection of services. These services need to inter-operate with each other to provide the functionality. This architecture requires a loose coupling with operating systems and other technologies that form the basis of the application. The loose coupling between services is required because each interaction has to be independent of the other. The communication between services could be either simple data being passed or it could be either an activity coordinated between distinct entities or services. Some means of interoperability is required to provide the services in larger terms. Instead of defining the [http://en.wikipedia.org/wiki/API API], the SOA implements the interfaces using the protocols and functionality. SOA separates functions into unique entities or services, which are accessed in a network by the users to combine and reuse them to develop the applications.

==Why SOA?==

Various businesses in the field of [http://en.wikipedia.org/wiki/Information_technology Information Technology] have to justify their projects with a return on their investments. This creates a pressure in Information Technology by making it a demanding field. Information Technology needs to have requirements in a way that it has to responsive and adapt to the changing requirements.

Information Technology companies must also be able to provide the services that are compatible with other services making it interoperable, thus creating dynamic services. Moreover, Information Technology has to face demands to bring new commercial services to a much wider array of customers. Customers may access services through web interfaces, or may be part of a supply chain that needs to decrease the time and cost of manufacturing.

Thus, Information Technology companies are always on the look out for solutions that will help them meet the above demands – without having to spend a lot of money. [http://en.wikipedia.org/wiki/Service_oriented_architecture Service Oriented Architecture] offers a solution to satisfy the above needs of the industry

==SOA-Benifits==
In architectural terms, a modern architectural design should be Service Oriented, loosely coupled, driven by events, able to support both integration and assembly, aligned with valuable life cycle support processes, and able to leverage existing infrastructure and applications.

When it comes to Service Oriented Architecture, it tends to offer a variety of different advantages over more traditional methods of distributing computing. These include
i) business services across several platforms
ii) location independence
iii) authentication as well as authorization support on different platforms
iv ) loosely coupled approach, dynamic search and connectivity to other services.

=Design Patterns in SOA=
A [http://en.wikipedia.org/wiki/Design_pattern design pattern] is a general reusable solution to a commonly occurring problem in software design. A design pattern is not a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be applied in different scenarios. Design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved.

Design patterns play a major role in SOA. The implementation and deployment of SOA designs provide different challenges during product development life cycle.Such challenges may make projects to be discontinued. Design patterns help in overcoming these problems by providing a solution to the problems posed. Each SOA design pattern provides a design solution in support of
successfully applying service orientation and establishing a quality service-oriented architecture

=Design Patterns proposed =

The proposed Design Patterns for SOA fall in to following categories. They are listed below and corresponding patterns in
each category are given. Detailed explanation of the design patterns given in the example can be found in the link provided for each category.

[http://www.soapatterns.org/masterlist_c.asp#ch6 Foundational Inventory Patterns]

These design patterns focus on providing solutions to the problems like maximizing re-composition and avoiding redundant logic.

Examples include Enterprise Inventory, Domain Inventory, Service Normalization, Logic Centralization, Service Layers Canonical Protocol, Canonical Schema

[http://www.soapatterns.org/masterlist_c.asp#ch7 Logical Inventory Layer Patterns]

These design patterns provide the solution to the problem of how can business logic be separated, reused, and governed independently?

examples for this category are Utility Abstraction,Entity Abstraction,Process Abstraction

[http://www.soapatterns.org/masterlist_c.asp#ch8 Inventory Centralization Patterns]

These patterns focus on providing solution for aspect of governing business logic etc

examples for this category are Process Centralization,Schema Centralization,Policy Centralization,Rules Centralization.

[http://www.soapatterns.org/masterlist_c.asp#ch9 Inventory Implementation Patterns]

These patterns help to solve implementation problems like limitations introduced by communication technology. Example like a single protocol may not accommodate all requirements etc

examples for this category are Dual Protocols,Canonical Resources,State Repository,Stateful Services,Service Grid,Inventory Endpoint,Cross-Domain Utility Layer

[http://www.soapatterns.org/masterlist_c.asp#ch10 Inventory Governance Patterns]

The patterns deal with the governance problems caused by service contract within the same service inventory

examples for this category are Canonical Expression,Metadata Centralization,Canonical Versioning

[http://www.soapatterns.org/masterlist_c.asp#ch11 Foundational Service Patterns]

The patterns proposed in this category focus on solving large business problems without having to build a stand alone solution.

examples for this category are Functional Decomposition,Service Encapsulation,Agnostic Context,Non-Agnostic Context,Agnostic Capability

[http://www.soapatterns.org/masterlist_c.asp#ch12 Service Implementation Patterns]

The patterns in this category focus on improving the realiability and availability of the service

examples for this category are Service Facade,Redundant Implementation,Service Data Replication,Partial State Deferral,Partial Validation,UI Mediator

[http://www.soapatterns.org/masterlist_c.asp#ch13 Service Security Patterns]

The patterns proposed in this category deal with the problem of data encapsulation and security aspects.

examples for this category are Exception Shielding,Message Screening,Trusted Subsystem ,Service Perimeter Guard

[http://www.soapatterns.org/masterlist_c.asp#ch14 Service Contract Design Patterns]

The patterns proposed in this category focus on providing solution for how to make the service contract suitable for all potential customers,make it aligned with other services etc

examples for this category are Decoupled Contract,Contract Centralization,Contract De normalization,Concurrent Contracts,Validation Abstraction

[http://www.soapatterns.org/masterlist_c.asp#ch15 Legacy Encapsulation Patterns]

The patterns proposed deals with the problems in legacy systems like processing of data contained in flat files, redundancy resulting in delivery to multiple channels etc

examples for this category are Legacy Wrapper, Multi-Channel Endpoint,File Gateway

[http://www.soapatterns.org/masterlist_c.asp#ch16 Service Governance Patterns]

These patterns provide solution for problems like updating the customers with changed service so that they are not affected, modifications in service etc

examples for this category are Compatible Change,Version Identification,Termination Notification,Service Refactoring,Service Decomposition,Proxy Capability,Decomposed Capability,Distributed Capability

[http://www.soapatterns.org/masterlist_c.asp#ch17 Capability Composition Patterns]

The pattern proposed focuses on the problem of How can a service capability solve a problem that requires logic outside of the service boundary and How can the same capability be used to help solve multiple problems?

examples for this category are Capability Composition,Capability Recomposition

[http://www.soapatterns.org/masterlist_c.asp#ch18 Service Messaging Patterns]

The patterns proposed in this category focus on setting up of message framework for transfer of data.

examples in this category are Service Messaging,Messaging Metadata,Service Agent,Intermediate Routing,State Messaging,Service Callback,Service Instance Routing,Asynchronous Queuing,Reliable Messaging,Event-Driven Messaging.

[http://www.soapatterns.org/masterlist_c.asp#ch19 Composition Implementation Patterns]

The patterns proposed in this category focus on problems during runtime like runtime activities that span multiple services fail, the parent business task is incomplete etc

examples for this category are Agnostic SubController,Composition Autonomy,Atomic Service Transaction,Compensating ServiceTransaction

[http://www.soapatterns.org/masterlist_c.asp#ch20 Service Interaction Security Patterns]

The proposed patterns in this category are focused on security methods like encryption,decryption,authenticating the data,consumer and service

examples for this category are Data Confidentiality, Data Origin Authentication, Direct Authentication, Brokered Authentication

[http://www.soapatterns.org/masterlist_c.asp#ch21 Transformation Patterns]

The Patterns proposed in this category concrete on how data from one data model can be dynamically converted to comply to a different data model.

examples for this category are Data Model Transformation,Data Format Transformation, Protocol Bridging

[http://www.soapatterns.org/masterlist_c.asp#ch22 Common Compound Design Patterns]

A compound pattern is a coarse-grained pattern comprised of a set of finer-grained patterns.

examples for this category are Orchestration,Enterprise Service Bus,Service Broker,Canonical Schema Bus,Official Endpoint,Federated Endpoint Layer,Three-Layer Inventory

=Example Design Patterns =

The following section describes five design patterns which are utilized in SOA. The described patterns provide the problem and corresponding solution.The figures for the following examples are taken from corresponding sections of [http://www.soapatterns.org/masterlist_a.asp soapatterns.org]

==Canonical protocol==

[[Image:Canonicalpattern.jpg.png]]

''Canonical Protocol Figure as given in SOA Patterns website''

Problem: Services that support different communication technologies compromise interoperability, limit the quantity of potential consumers, and introduce the need for undesirable protocol bridging measures.

Solution: The architecture establishes a single communications technology as the sole or primary medium by which services can interact.

From the above figure it is observed that the services are delivered by three different communication technologies A,B and C.These services are made to conform to one centralized communications technology, making them technologically compatible.with this these services can be delivered to consumers without much difficulty

==Dual protocol==

[[Image:dualprotocol.png]]

Problem: Canonical Protocol requires that all services conform to the use of the same communications technology; however, a single protocol may not be able to accommodate all service requirements, thereby introducing limitations.

Solution: The service inventory architecture is designed to support services based on primary and secondary protocols.

Regardless of protocol, all services must invoke each other via their official service contracts (A, B). Bypassing the contract may seem convenient when the underlying service logic of the primary service supports the same protocol as the secondary service (C), but it is an anti-pattern that will eventually inhibit the application of this pattern and further weaken the overall service inventory foundation.

==Protocol Bridging==

[[Image:protocolbridging.png]]

Problem: Services using different communication protocols or different versions of the same protocol cannot exchange data.

Solution: Bridging logic is introduced to enable communication between different communication protocols by dynamically converting one protocol to another at runtime.

From the above figure it can be noticed that the consumer programs interact with a middle-tier broker that provides protocol bridging features.The consumer programs may be using different protocols like [http://java.sun.com/products/jms/ JMS] or SOAP 1.1.In order to translate the two incompatible protocols in to the required SOAP 1,2 with HTTP separate protocol adapters are used in the broker. The broker then transmits the messages to the service on behalf of the consumers.Therefore the protocol bridging is achieved.

==UI Mediator==

[[Image:uimediator.png]]

Problem: Because the behavior of individual services can vary depending on their design,runtime usage, and the workload required to carry out a given capability, the consistency with which a service-oriented solution can respond to requests originating from a user-interface can fluctuate, leading to a poor user experience.

Solution: Establish mediator logic solely responsible for ensuring timely interaction and feedback with user-interfaces and presentation logic.

In this method as can be observed from the figure the three services A,B and C work behind the scenes to complete the given task.The mediator service (D) regularly updates the user interface there by hiding the underlying logic to the consumer.

==Service Facade==

[[Image:service_facade.png]]

Problem: The coupling of the core service logic to contracts and implementation resources can inhibit its evolution and negatively impact service consumers.

Solution: A service facade component is used to abstract a part of the service architecture with negative coupling potential.

Facade logic is placed in between the contract and the core service logic. This allows the core service logic to remain decoupled from the contract.The objective of loose coupling is achieved by this process.the core logic abstraction is obtained by this way.

=Similarities and Differences Between Patterns for SOA and Traditional pattens proposed by GoF=

The Gang of Four(Gof) comprising of Eric Gamma, Richard Helm, Ralph Johnson, and John Vlissides have documented the design patterns that were followed by Software developers and architects in object oriented space. They have documented 23 design patterns which are collectively called as Traditional design patterns.

The design patterns in SOA are similiar in some aspects to the traditional patterns.They also differ from the traditional patterns. The similiarities and differences between them are provided in this section

==Differences==

The differences between the SOA design patterns and traditional design patterns have been come up based on the individual functionality that each pattern provide. Following are the differences,

1) The [http://en.wikipedia.org/wiki/Composite_pattern composite pattern] organizes the objects in the manner to represent the part-whole hierarchies in a traditional two-tier hierarchy.

The [http://www.soapatterns.org/agnostic_subcontroller.asp agnostic sub-controller] implements the service composability but it differs from the composite pattern in such a way that cross-entity functionality is abstracted and made accessible through the sub –controller capability.

For instance, the traditional composite pattern has the object representing a part-whole hierarchy as in the below figure of graphic class which has draw(). If we require a cross-entity functionality as in the below figure, we require a colored rectangle, we require the functionality fill() of color class. Hence the sub-controller module is created which has the functionality of different parents, thus making it reusable.

Figure to illustrate above difference

[[Image:Composite_example.png]]

2)
The traditional [http://en.wikipedia.org/wiki/Bridge_pattern bridge pattern] separates the abstraction from its implementation in order to vary independently. Whereas the [http://www.soapatterns.org/canonical_protocol.asp canonical protocol] avoids the protocol bridging in such a way that there is a single communication technology through which the services can interact.

In the below figure of bridge pattern, the relationship between the abstraction and implementor is bridge and it results the implementor to vary independently from the abstraction by having different ConcreteImplementor. The canonical protocol avoids the variation by having a single communication technology between different objects.

Figure for above difference

[[Image:Traditional_bridge.png]]
Figure for Traditional bridge pattern

For canonical protocol refer to the explanation given in example design patterns

3) The traditional [http://en.wikipedia.org/wiki/Builder_pattern builder pattern] decouples the construction of the object from its representation so that the same construction process can be used to develop different representations. The different representations (contracts) are addressed in SOA by the [http://www.soapatterns.org/concurrent_contracts.asp Concurrent Contracts] with the application of [http://www.soapatterns.org/service_facade.asp Service-façade] design pattern. With service-façade design pattern, an abstraction is created to support the interaction between different contracts. As a result, different contracts can be created for a single service.

In the below figure, the conversion of the text document is separated from the reader of RTF document, so that the text document can be represented in different forms like ASCIIText, TeXText and TextWidget. The different representation is achieved by decoupling of construction and abstraction. In the case of concurrent contracts pattern, the different contracts or services (invoices) are created for different consumer through service-façade by creating a new abstraction.

[[Image:Builder.png]]
Figure for Traditional Builder pattern

[[Image:Concurrent_pattern.png]]
Figure for Concurrent pattern

==Similarities==
1) The [http://www.soapatterns.org/service_facade.asp Service-façade] design pattern is similar to the [http://en.wikipedia.org/wiki/Facade_pattern façade] (traditional) pattern in the manner that it implements the façade logic which is creating an abstraction for intra-communication within objects to the service architecture. The advantage by adding the façade logic to the service architecture is that it preserves the underlying logic from run-time changes.

2) The [http://www.soapatterns.org/ui_mediator.asp UI Mediator] design pattern implements the [http://en.wikipedia.org/wiki/Mediator_pattern mediator] logic of traditional mediator pattern. The mediator logic aims to provide the user responses in a way that user understands, independently of what the underlying services perform.

3) The [http://www.soapatterns.org/intermediate_routing.asp Intermediate routing] pattern in SOA is similar to [http://en.wikipedia.org/wiki/Decorator_pattern Decorator pattern] (traditional) in the functionality that it adds the required logic at run-time. The decorator adds the additional functionality to the object at run-time. The intermediate routing pattern is about placing the routing logic to address the run-time scenarios.

4)The [http://www.soapatterns.org/capability_composition.asp Capability Composition] pattern in SOA implements the [http://en.wikipedia.org/wiki/Composite_pattern Composite pattern] (traditional). The Capability Composition is about composing one or more capabilities outside the service’s context to address the large, complex problem.

5) The [http://www.soapatterns.org/decoupled_contract.asp Decoupled Contract] pattern implements the traditional [http://en.wikipedia.org/wiki/Bridge_pattern Bridge pattern] in the manner that service contract is separated from the implementation. The Bridge pattern decouples the abstraction from implementation to facilitate the variation of both (abstraction and implementation).

6) The [http://www.soapatterns.org/legacy_wrapper.asp Legacy Wrapper] pattern is related to traditional [http://en.wikipedia.org/wiki/Adapter_pattern Adapter pattern]. The Legacy Wrapper pattern protects the legacy logic by providing a standard service that takes of protecting the legacy details by encapsulating, extraction or elimination. The encapsulation, extraction or elimination is done in order to change the service as the consumer requires it. This is related to adapter in a way that it converts the interface of one class to another as the client expects.

=Summary=
The various patterns in Service oriented Architecture which have been currently proposed were studied and an attempt was made to document all of them by categories.Few detailed examples are documented to get an understanding of the underlying process.Specific comparison of design patterns in SOA domain and corresponding traditional patterns has been carried out.The design patterns in SOA are still under development and many patterns are coming up due to vast technology used in this domain.

=Glossary=

1.Serive : "A service is a discoverable resource that executes a repeatable task, and is described by an externalized service specification."

2.[http://www.ibm.com/developerworks/webservices/library/ws-soa-term1/ SOA Terminology]

3.SOA :[http://en.wikipedia.org/wiki/Service-oriented_architecture Service oriented Architecture]

4.API :[http://en.wikipedia.org/wiki/Application_programming_interface Application programming interface]

5.SOAP :[http://en.wikipedia.org/wiki/SOAP Simple Object Access Protocol]

6.HTTP :[http://en.wikipedia.org/wiki/HyperText_Transfer_Protocol Hypertext Transfer Protocol]

7.GoF :[http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Gang of Four]

8.[http://soaglossary.com/ SOA Glossory]

=References=

1.[http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Design patterns for object oriented software]

2.[http://en.wikipedia.org/wiki/Service-oriented_architecture#Introduction Service Oriented Architecture]

3.[http://www.exforsys.com/tutorials/soa/soa-definitions-and-certification.html SOA Tutorial]

4.[http://www.soapatterns.org/ soa design patterns]

5.[http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29 design pattern]

6.[http://www.oracle.com/technologies/soa/center.html oracle SOA centre]

7.[http://www.ibm.com/developerworks/webservices/library/ws-soa-term1/ IBMs SOA Contributions]

8.[http://www.oracle.com/technology/pub/articles/erl_soa_design_patterns_app_sequences.html SOA Design patterns application sequences by oracle]

9.SOA Design Patterns by Thomas Erl

CSC/ECE 517 Fall 2009/wiki2 16 rs

2009-10-15T00:46:07Z

Screenit: /* Canonical protocol */

CSC/ECE 517 Fall 2009/wiki2 16 rs

SOA provides another view of providing functionality based upon services offered in terms of protocols and a specific API. Research and report on what patterns have been proposed and are utilized within this domain. How do they differ from traditional design patterns proposed by Eric Gamma, Richard Helm, Ralph Johnson, and John Vlissides? How are they similar?

----
=Introduction=

This article focuses on the design patterns which are proposed and utilized in the [http://en.wikipedia.org/wiki/Service_oriented_architecture Service Oriented Architecture]. As the SOA provides its services through the protocols and API, this article throws light on the design patterns that specifically provide services through protocols like [http://www.soapatterns.org/canonical_protocol.asp Canonical protocol], [http://www.soapatterns.org/dual_protocols.asp Dual protocols] and [http://www.soapatterns.org/protocol_bridging.asp Protocol Bridging]. In a broader perspective, other design patterns have been explained tersely. In addition to explanation of the SOA design patterns, this compares the SOA design patterns with the traditional design patterns proposed by the ‘Gang of Four’ (Eric Gamma, Richard Helm, Ralph Johnson, and John Vlissides) and comes up with the differences and similarities between them.

=Service Oriented Architecture-An Overview=

==SOA-Definition==

A [http://en.wikipedia.org/wiki/Service_oriented_architecture Service Oriented Architecture] is an architecture that provides collection of services. These services need to inter-operate with each other to provide the functionality. This architecture requires a loose coupling with operating systems and other technologies that form the basis of the application. The loose coupling between services is required because each interaction has to be independent of the other. The communication between services could be either simple data being passed or it could be either an activity coordinated between distinct entities or services. Some means of interoperability is required to provide the services in larger terms. Instead of defining the [http://en.wikipedia.org/wiki/API API], the SOA implements the interfaces using the protocols and functionality. SOA separates functions into unique entities or services, which are accessed in a network by the users to combine and reuse them to develop the applications.

==Why SOA?==

Various businesses in the field of [http://en.wikipedia.org/wiki/Information_technology Information Technology] have to justify their projects with a return on their investments. This creates a pressure in Information Technology by making it a demanding field. Information Technology needs to have requirements in a way that it has to responsive and adapt to the changing requirements.

Information Technology companies must also be able to provide the services that are compatible with other services making it interoperable, thus creating dynamic services. Moreover, Information Technology has to face demands to bring new commercial services to a much wider array of customers. Customers may access services through web interfaces, or may be part of a supply chain that needs to decrease the time and cost of manufacturing.

Thus, Information Technology companies are always on the look out for solutions that will help them meet the above demands – without having to spend a lot of money. [http://en.wikipedia.org/wiki/Service_oriented_architecture Service Oriented Architecture] offers a solution to satisfy the above needs of the industry

==SOA-Benifits==
In architectural terms, a modern architectural design should be Service Oriented, loosely coupled, driven by events, able to support both integration and assembly, aligned with valuable life cycle support processes, and able to leverage existing infrastructure and applications.

When it comes to Service Oriented Architecture, it tends to offer a variety of different advantages over more traditional methods of distributing computing. These include
i) business services across several platforms
ii) location independence
iii) authentication as well as authorization support on different platforms
iv ) loosely coupled approach, dynamic search and connectivity to other services.

=Design Patterns in SOA=
A [http://en.wikipedia.org/wiki/Design_pattern design pattern] is a general reusable solution to a commonly occurring problem in software design. A design pattern is not a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be applied in different scenarios. Design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved.

Design patterns play a major role in SOA. The implementation and deployment of SOA designs provide different challenges during product development life cycle.Such challenges may make projects to be discontinued. Design patterns help in overcoming these problems by providing a solution to the problems posed. Each SOA design pattern provides a design solution in support of
successfully applying service orientation and establishing a quality service-oriented architecture

=Design Patterns proposed =

The proposed Design Patterns for SOA fall in to following categories. They are listed below and corresponding patterns in
each category are given. Detailed explanation of the design patterns given in the example can be found in the link provided for each category.

[http://www.soapatterns.org/masterlist_c.asp#ch6 Foundational Inventory Patterns]

These design patterns focus on providing solutions to the problems like maximizing re-composition and avoiding redundant logic.

Examples include Enterprise Inventory, Domain Inventory, Service Normalization, Logic Centralization, Service Layers Canonical Protocol, Canonical Schema

[http://www.soapatterns.org/masterlist_c.asp#ch7 Logical Inventory Layer Patterns]

These design patterns provide the solution to the problem of how can business logic be separated, reused, and governed independently?

examples for this category are Utility Abstraction,Entity Abstraction,Process Abstraction

[http://www.soapatterns.org/masterlist_c.asp#ch8 Inventory Centralization Patterns]

These patterns focus on providing solution for aspect of governing business logic etc

examples for this category are Process Centralization,Schema Centralization,Policy Centralization,Rules Centralization.

[http://www.soapatterns.org/masterlist_c.asp#ch9 Inventory Implementation Patterns]

These patterns help to solve implementation problems like limitations introduced by communication technology. Example like a single protocol may not accommodate all requirements etc

examples for this category are Dual Protocols,Canonical Resources,State Repository,Stateful Services,Service Grid,Inventory Endpoint,Cross-Domain Utility Layer

[http://www.soapatterns.org/masterlist_c.asp#ch10 Inventory Governance Patterns]

The patterns deal with the governance problems caused by service contract within the same service inventory

examples for this category are Canonical Expression,Metadata Centralization,Canonical Versioning

[http://www.soapatterns.org/masterlist_c.asp#ch11 Foundational Service Patterns]

The patterns proposed in this category focus on solving large business problems without having to build a stand alone solution.

examples for this category are Functional Decomposition,Service Encapsulation,Agnostic Context,Non-Agnostic Context,Agnostic Capability

[http://www.soapatterns.org/masterlist_c.asp#ch12 Service Implementation Patterns]

The patterns in this category focus on improving the realiability and availability of the service

examples for this category are Service Facade,Redundant Implementation,Service Data Replication,Partial State Deferral,Partial Validation,UI Mediator

[http://www.soapatterns.org/masterlist_c.asp#ch13 Service Security Patterns]

The patterns proposed in this category deal with the problem of data encapsulation and security aspects.

examples for this category are Exception Shielding,Message Screening,Trusted Subsystem ,Service Perimeter Guard

[http://www.soapatterns.org/masterlist_c.asp#ch14 Service Contract Design Patterns]

The patterns proposed in this category focus on providing solution for how to make the service contract suitable for all potential customers,make it aligned with other services etc

examples for this category are Decoupled Contract,Contract Centralization,Contract De normalization,Concurrent Contracts,Validation Abstraction

[http://www.soapatterns.org/masterlist_c.asp#ch15 Legacy Encapsulation Patterns]

The patterns proposed deals with the problems in legacy systems like processing of data contained in flat files, redundancy resulting in delivery to multiple channels etc

examples for this category are Legacy Wrapper, Multi-Channel Endpoint,File Gateway

[http://www.soapatterns.org/masterlist_c.asp#ch16 Service Governance Patterns]

These patterns provide solution for problems like updating the customers with changed service so that they are not affected, modifications in service etc

examples for this category are Compatible Change,Version Identification,Termination Notification,Service Refactoring,Service Decomposition,Proxy Capability,Decomposed Capability,Distributed Capability

[http://www.soapatterns.org/masterlist_c.asp#ch17 Capability Composition Patterns]

The pattern proposed focuses on the problem of How can a service capability solve a problem that requires logic outside of the service boundary and How can the same capability be used to help solve multiple problems?

examples for this category are Capability Composition,Capability Recomposition

[http://www.soapatterns.org/masterlist_c.asp#ch18 Service Messaging Patterns]

The patterns proposed in this category focus on setting up of message framework for transfer of data.

examples in this category are Service Messaging,Messaging Metadata,Service Agent,Intermediate Routing,State Messaging,Service Callback,Service Instance Routing,Asynchronous Queuing,Reliable Messaging,Event-Driven Messaging.

[http://www.soapatterns.org/masterlist_c.asp#ch19 Composition Implementation Patterns]

The patterns proposed in this category focus on problems during runtime like runtime activities that span multiple services fail, the parent business task is incomplete etc

examples for this category are Agnostic SubController,Composition Autonomy,Atomic Service Transaction,Compensating ServiceTransaction

[http://www.soapatterns.org/masterlist_c.asp#ch20 Service Interaction Security Patterns]

The proposed patterns in this category are focused on security methods like encryption,decryption,authenticating the data,consumer and service

examples for this category are Data Confidentiality, Data Origin Authentication, Direct Authentication, Brokered Authentication

[http://www.soapatterns.org/masterlist_c.asp#ch21 Transformation Patterns]

The Patterns proposed in this category concrete on how data from one data model can be dynamically converted to comply to a different data model.

examples for this category are Data Model Transformation,Data Format Transformation, Protocol Bridging

[http://www.soapatterns.org/masterlist_c.asp#ch22 Common Compound Design Patterns]

A compound pattern is a coarse-grained pattern comprised of a set of finer-grained patterns.

examples for this category are Orchestration,Enterprise Service Bus,Service Broker,Canonical Schema Bus,Official Endpoint,Federated Endpoint Layer,Three-Layer Inventory

=Example Design Patterns =

The following section describes five design patterns which are utilized in SOA. The described patterns provide the problem and corresponding solution.The figures for the following examples are taken from corresponding sections of [http://www.soapatterns.org/masterlist_a.asp soapatterns.org]

==Canonical protocol==

[[Image:Canonicalpattern.jpg.png]]

Canonical Protocol Figure as given in SOA Patterns website

Problem: Services that support different communication technologies compromise interoperability, limit the quantity of potential consumers, and introduce the need for undesirable protocol bridging measures.

Solution: The architecture establishes a single communications technology as the sole or primary medium by which services can interact.

From the above figure it is observed that the services are delivered by three different communication technologies A,B and C.These services are made to conform to one centralized communications technology, making them technologically compatible.with this these services can be delivered to consumers without much difficulty

==Dual protocol==

[[Image:dualprotocol.png]]

Problem: Canonical Protocol requires that all services conform to the use of the same communications technology; however, a single protocol may not be able to accommodate all service requirements, thereby introducing limitations.

Solution: The service inventory architecture is designed to support services based on primary and secondary protocols.

Regardless of protocol, all services must invoke each other via their official service contracts (A, B). Bypassing the contract may seem convenient when the underlying service logic of the primary service supports the same protocol as the secondary service (C), but it is an anti-pattern that will eventually inhibit the application of this pattern and further weaken the overall service inventory foundation.

==Protocol Bridging==

[[Image:protocolbridging.png]]

Problem: Services using different communication protocols or different versions of the same protocol cannot exchange data.

Solution: Bridging logic is introduced to enable communication between different communication protocols by dynamically converting one protocol to another at runtime.

From the above figure it can be noticed that the consumer programs interact with a middle-tier broker that provides protocol bridging features.The consumer programs may be using different protocols like [http://java.sun.com/products/jms/ JMS] or SOAP 1.1.In order to translate the two incompatible protocols in to the required SOAP 1,2 with HTTP separate protocol adapters are used in the broker. The broker then transmits the messages to the service on behalf of the consumers.Therefore the protocol bridging is achieved.

==UI Mediator==

[[Image:uimediator.png]]

Problem: Because the behavior of individual services can vary depending on their design,runtime usage, and the workload required to carry out a given capability, the consistency with which a service-oriented solution can respond to requests originating from a user-interface can fluctuate, leading to a poor user experience.

Solution: Establish mediator logic solely responsible for ensuring timely interaction and feedback with user-interfaces and presentation logic.

In this method as can be observed from the figure the three services A,B and C work behind the scenes to complete the given task.The mediator service (D) regularly updates the user interface there by hiding the underlying logic to the consumer.

==Service Facade==

[[Image:service_facade.png]]

Problem: The coupling of the core service logic to contracts and implementation resources can inhibit its evolution and negatively impact service consumers.

Solution: A service facade component is used to abstract a part of the service architecture with negative coupling potential.

Facade logic is placed in between the contract and the core service logic. This allows the core service logic to remain decoupled from the contract.The objective of loose coupling is achieved by this process.the core logic abstraction is obtained by this way.

=Similarities and Differences Between Patterns for SOA and Traditional pattens proposed by GoF=

The Gang of Four(Gof) comprising of Eric Gamma, Richard Helm, Ralph Johnson, and John Vlissides have documented the design patterns that were followed by Software developers and architects in object oriented space. They have documented 23 design patterns which are collectively called as Traditional design patterns.

The design patterns in SOA are similiar in some aspects to the traditional patterns.They also differ from the traditional patterns. The similiarities and differences between them are provided in this section

==Differences==

The differences between the SOA design patterns and traditional design patterns have been come up based on the individual functionality that each pattern provide. Following are the differences,

1) The [http://en.wikipedia.org/wiki/Composite_pattern composite pattern] organizes the objects in the manner to represent the part-whole hierarchies in a traditional two-tier hierarchy.

The [http://www.soapatterns.org/agnostic_subcontroller.asp agnostic sub-controller] implements the service composability but it differs from the composite pattern in such a way that cross-entity functionality is abstracted and made accessible through the sub –controller capability.

For instance, the traditional composite pattern has the object representing a part-whole hierarchy as in the below figure of graphic class which has draw(). If we require a cross-entity functionality as in the below figure, we require a colored rectangle, we require the functionality fill() of color class. Hence the sub-controller module is created which has the functionality of different parents, thus making it reusable.

Figure to illustrate above difference

[[Image:Composite_example.png]]

2)
The traditional [http://en.wikipedia.org/wiki/Bridge_pattern bridge pattern] separates the abstraction from its implementation in order to vary independently. Whereas the [http://www.soapatterns.org/canonical_protocol.asp canonical protocol] avoids the protocol bridging in such a way that there is a single communication technology through which the services can interact.

In the below figure of bridge pattern, the relationship between the abstraction and implementor is bridge and it results the implementor to vary independently from the abstraction by having different ConcreteImplementor. The canonical protocol avoids the variation by having a single communication technology between different objects.

Figure for above difference

[[Image:Traditional_bridge.png]]
Figure for Traditional bridge pattern

For canonical protocol refer to the explanation given in example design patterns

3) The traditional [http://en.wikipedia.org/wiki/Builder_pattern builder pattern] decouples the construction of the object from its representation so that the same construction process can be used to develop different representations. The different representations (contracts) are addressed in SOA by the [http://www.soapatterns.org/concurrent_contracts.asp Concurrent Contracts] with the application of [http://www.soapatterns.org/service_facade.asp Service-façade] design pattern. With service-façade design pattern, an abstraction is created to support the interaction between different contracts. As a result, different contracts can be created for a single service.

In the below figure, the conversion of the text document is separated from the reader of RTF document, so that the text document can be represented in different forms like ASCIIText, TeXText and TextWidget. The different representation is achieved by decoupling of construction and abstraction. In the case of concurrent contracts pattern, the different contracts or services (invoices) are created for different consumer through service-façade by creating a new abstraction.

[[Image:Builder.png]]
Figure for Traditional Builder pattern

[[Image:Concurrent_pattern.png]]
Figure for Concurrent pattern

==Similarities==
1) The [http://www.soapatterns.org/service_facade.asp Service-façade] design pattern is similar to the [http://en.wikipedia.org/wiki/Facade_pattern façade] (traditional) pattern in the manner that it implements the façade logic which is creating an abstraction for intra-communication within objects to the service architecture. The advantage by adding the façade logic to the service architecture is that it preserves the underlying logic from run-time changes.

2) The [http://www.soapatterns.org/ui_mediator.asp UI Mediator] design pattern implements the [http://en.wikipedia.org/wiki/Mediator_pattern mediator] logic of traditional mediator pattern. The mediator logic aims to provide the user responses in a way that user understands, independently of what the underlying services perform.

3) The [http://www.soapatterns.org/intermediate_routing.asp Intermediate routing] pattern in SOA is similar to [http://en.wikipedia.org/wiki/Decorator_pattern Decorator pattern] (traditional) in the functionality that it adds the required logic at run-time. The decorator adds the additional functionality to the object at run-time. The intermediate routing pattern is about placing the routing logic to address the run-time scenarios.

4)The [http://www.soapatterns.org/capability_composition.asp Capability Composition] pattern in SOA implements the [http://en.wikipedia.org/wiki/Composite_pattern Composite pattern] (traditional). The Capability Composition is about composing one or more capabilities outside the service’s context to address the large, complex problem.

5) The [http://www.soapatterns.org/decoupled_contract.asp Decoupled Contract] pattern implements the traditional [http://en.wikipedia.org/wiki/Bridge_pattern Bridge pattern] in the manner that service contract is separated from the implementation. The Bridge pattern decouples the abstraction from implementation to facilitate the variation of both (abstraction and implementation).

6) The [http://www.soapatterns.org/legacy_wrapper.asp Legacy Wrapper] pattern is related to traditional [http://en.wikipedia.org/wiki/Adapter_pattern Adapter pattern]. The Legacy Wrapper pattern protects the legacy logic by providing a standard service that takes of protecting the legacy details by encapsulating, extraction or elimination. The encapsulation, extraction or elimination is done in order to change the service as the consumer requires it. This is related to adapter in a way that it converts the interface of one class to another as the client expects.

=Summary=
The various patterns in Service oriented Architecture which have been currently proposed were studied and an attempt was made to document all of them by categories.Few detailed examples are documented to get an understanding of the underlying process.Specific comparison of design patterns in SOA domain and corresponding traditional patterns has been carried out.The design patterns in SOA are still under development and many patterns are coming up due to vast technology used in this domain.

=Glossary=

1.Serive : "A service is a discoverable resource that executes a repeatable task, and is described by an externalized service specification."

2.[http://www.ibm.com/developerworks/webservices/library/ws-soa-term1/ SOA Terminology]

3.SOA :[http://en.wikipedia.org/wiki/Service-oriented_architecture Service oriented Architecture]

4.API :[http://en.wikipedia.org/wiki/Application_programming_interface Application programming interface]

5.SOAP :[http://en.wikipedia.org/wiki/SOAP Simple Object Access Protocol]

6.HTTP :[http://en.wikipedia.org/wiki/HyperText_Transfer_Protocol Hypertext Transfer Protocol]

7.GoF :[http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Gang of Four]

8.[http://soaglossary.com/ SOA Glossory]

=References=

1.[http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Design patterns for object oriented software]

2.[http://en.wikipedia.org/wiki/Service-oriented_architecture#Introduction Service Oriented Architecture]

3.[http://www.exforsys.com/tutorials/soa/soa-definitions-and-certification.html SOA Tutorial]

4.[http://www.soapatterns.org/ soa design patterns]

5.[http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29 design pattern]

6.[http://www.oracle.com/technologies/soa/center.html oracle SOA centre]

7.[http://www.ibm.com/developerworks/webservices/library/ws-soa-term1/ IBMs SOA Contributions]

8.[http://www.oracle.com/technology/pub/articles/erl_soa_design_patterns_app_sequences.html SOA Design patterns application sequences by oracle]

9.SOA Design Patterns by Thomas Erl

CSC/ECE 517 Fall 2009/wiki2 16 rs

2009-10-10T03:19:21Z

Screenit: /* SOA-Definition */

CSC/ECE 517 Fall 2009/wiki2 16 rs

SOA provides another view of providing functionality based upon services offered in terms of protocols and a specific API. Research and report on what patterns have been proposed and are utilized within this domain. How do they differ from traditional design patterns proposed by Eric Gamma, Richard Helm, Ralph Johnson, and John Vlissides? How are they similar?

----
=Introduction=

This article focuses on the design patterns which are proposed and utilized in the [http://en.wikipedia.org/wiki/Service_oriented_architecture Service Oriented Architecture]. As the SOA provides its services through the protocols and API, this article throws light on the design patterns that specifically provide services through protocols like [http://www.soapatterns.org/canonical_protocol.asp Canonical protocol], [http://www.soapatterns.org/dual_protocols.asp Dual protocols] and [http://www.soapatterns.org/protocol_bridging.asp Protocol Bridging]. In a broader perspective, other design patterns have been explained tersely. In addition to explanation of the SOA design patterns, this compares the SOA design patterns with the traditional design patterns proposed by the ‘Gang of Four’ (Eric Gamma, Richard Helm, Ralph Johnson, and John Vlissides) and comes up with the differences and similarities between them.

=Service Oriented Architecture-An Overview=

==SOA-Definition==

A [http://en.wikipedia.org/wiki/Service_oriented_architecture Service Oriented Architecture] is an architecture that provides collection of services. These services need to inter-operate with each other to provide the functionality. This architecture requires a loose coupling with operating systems and other technologies that form the basis of the application. The loose coupling between services is required because each interaction has to be independent of the other. The communication between services could be either simple data being passed or it could be either an activity coordinated between distinct entities or services. Some means of interoperability is required to provide the services in larger terms. Instead of defining the [http://en.wikipedia.org/wiki/API API], the SOA implements the interfaces using the protocols and functionality. SOA separates functions into unique entities or services, which are accessed in a network by the users to combine and reuse them to develop the applications.

==Why SOA?==

Various businesses in the field of [http://en.wikipedia.org/wiki/Information_technology Information Technology] have to justify their projects with a return on their investments. This creates a pressure in Information Technology by making it a demanding field. Information Technology needs to have requirements in a way that it has to responsive and adapt to the changing requirements.

Information Technology companies must also be able to provide the services that are compatible with other services making it interoperable, thus creating dynamic services. Moreover, Information Technology has to face demands to bring new commercial services to a much wider array of customers. Customers may access services through web interfaces, or may be part of a supply chain that needs to decrease the time and cost of manufacturing.

Thus, Information Technology companies are always on the look out for solutions that will help them meet the above demands – without having to spend a lot of money. [http://en.wikipedia.org/wiki/Service_oriented_architecture Service Oriented Architecture] offers a solution to satisfy the above needs of the industry

==SOA-Benifits==
In architectural terms, a modern architectural design should be Service Oriented, loosely coupled, driven by events, able to support both integration and assembly, aligned with valuable life cycle support processes, and able to leverage existing infrastructure and applications.

When it comes to Service Oriented Architecture, it tends to offer a variety of different advantages over more traditional methods of distributing computing. These include
i) business services across several platforms
ii) location independence
iii) authentication as well as authorization support on different platforms
iv ) loosely coupled approach, dynamic search and connectivity to other services.

=Design Patterns in SOA=
A [http://en.wikipedia.org/wiki/Design_pattern design pattern] is a general reusable solution to a commonly occurring problem in software design. A design pattern is not a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be applied in different scenarios. Design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved.

Design patterns play a major role in SOA. The implementation and deployment of SOA designs provide different challenges during product development life cycle.Such challenges may make projects to be discontinued. Design patterns help in overcoming these problems by providing a solution to the problems posed. Each SOA design pattern provides a design solution in support of
successfully applying service orientation and establishing a quality service-oriented architecture

=Design Patterns proposed =

The proposed Design Patterns for SOA fall in to following categories. They are listed below and corresponding patterns in
each category are given. Detailed explanation of the design patterns given in the example can be found in the link provided for each category.

[http://www.soapatterns.org/masterlist_c.asp#ch6 Foundational Inventory Patterns]

These design patterns focus on providing solutions to the problems like maximizing re-composition and avoiding redundant logic.

Examples include Enterprise Inventory, Domain Inventory, Service Normalization, Logic Centralization, Service Layers Canonical Protocol, Canonical Schema

[http://www.soapatterns.org/masterlist_c.asp#ch7 Logical Inventory Layer Patterns]

These design patterns provide the solution to the problem of how can business logic be separated, reused, and governed independently?

examples for this category are Utility Abstraction,Entity Abstraction,Process Abstraction

[http://www.soapatterns.org/masterlist_c.asp#ch8 Inventory Centralization Patterns]

These patterns focus on providing solution for aspect of governing business logic etc

examples for this category are Process Centralization,Schema Centralization,Policy Centralization,Rules Centralization.

[http://www.soapatterns.org/masterlist_c.asp#ch9 Inventory Implementation Patterns]

These patterns help to solve implementation problems like limitations introduced by communication technology. Example like a single protocol may not accommodate all requirements etc

examples for this category are Dual Protocols,Canonical Resources,State Repository,Stateful Services,Service Grid,Inventory Endpoint,Cross-Domain Utility Layer

[http://www.soapatterns.org/masterlist_c.asp#ch10 Inventory Governance Patterns]

The patterns deal with the governance problems caused by service contract within the same service inventory

examples for this category are Canonical Expression,Metadata Centralization,Canonical Versioning

[http://www.soapatterns.org/masterlist_c.asp#ch11 Foundational Service Patterns]

The patterns proposed in this category focus on solving large business problems without having to build a stand alone solution.

examples for this category are Functional Decomposition,Service Encapsulation,Agnostic Context,Non-Agnostic Context,Agnostic Capability

[http://www.soapatterns.org/masterlist_c.asp#ch12 Service Implementation Patterns]

The patterns in this category focus on improving the realiability and availability of the service

examples for this category are Service Facade,Redundant Implementation,Service Data Replication,Partial State Deferral,Partial Validation,UI Mediator

[http://www.soapatterns.org/masterlist_c.asp#ch13 Service Security Patterns]

The patterns proposed in this category deal with the problem of data encapsulation and security aspects.

examples for this category are Exception Shielding,Message Screening,Trusted Subsystem ,Service Perimeter Guard

[http://www.soapatterns.org/masterlist_c.asp#ch14 Service Contract Design Patterns]

The patterns proposed in this category focus on providing solution for how to make the service contract suitable for all potential customers,make it aligned with other services etc

examples for this category are Decoupled Contract,Contract Centralization,Contract De normalization,Concurrent Contracts,Validation Abstraction

[http://www.soapatterns.org/masterlist_c.asp#ch15 Legacy Encapsulation Patterns]

The patterns proposed deals with the problems in legacy systems like processing of data contained in flat files, redundancy resulting in delivery to multiple channels etc

examples for this category are Legacy Wrapper, Multi-Channel Endpoint,File Gateway

[http://www.soapatterns.org/masterlist_c.asp#ch16 Service Governance Patterns]

These patterns provide solution for problems like updating the customers with changed service so that they are not affected, modifications in service etc

examples for this category are Compatible Change,Version Identification,Termination Notification,Service Refactoring,Service Decomposition,Proxy Capability,Decomposed Capability,Distributed Capability

[http://www.soapatterns.org/masterlist_c.asp#ch17 Capability Composition Patterns]

The pattern proposed focuses on the problem of How can a service capability solve a problem that requires logic outside of the service boundary and How can the same capability be used to help solve multiple problems?

examples for this category are Capability Composition,Capability Recomposition

[http://www.soapatterns.org/masterlist_c.asp#ch18 Service Messaging Patterns]

The patterns proposed in this category focus on setting up of message framework for transfer of data.

examples in this category are Service Messaging,Messaging Metadata,Service Agent,Intermediate Routing,State Messaging,Service Callback,Service Instance Routing,Asynchronous Queuing,Reliable Messaging,Event-Driven Messaging.

[http://www.soapatterns.org/masterlist_c.asp#ch19 Composition Implementation Patterns]

The patterns proposed in this category focus on problems during runtime like runtime activities that span multiple services fail, the parent business task is incomplete etc

examples for this category are Agnostic SubController,Composition Autonomy,Atomic Service Transaction,Compensating ServiceTransaction

[http://www.soapatterns.org/masterlist_c.asp#ch20 Service Interaction Security Patterns]

The proposed patterns in this category are focused on security methods like encryption,decryption,authenticating the data,consumer and service

examples for this category are Data Confidentiality, Data Origin Authentication, Direct Authentication, Brokered Authentication

[http://www.soapatterns.org/masterlist_c.asp#ch21 Transformation Patterns]

The Patterns proposed in this category concrete on how data from one data model can be dynamically converted to comply to a different data model.

examples for this category are Data Model Transformation,Data Format Transformation, Protocol Bridging

[http://www.soapatterns.org/masterlist_c.asp#ch22 Common Compound Design Patterns]

A compound pattern is a coarse-grained pattern comprised of a set of finer-grained patterns.

examples for this category are Orchestration,Enterprise Service Bus,Service Broker,Canonical Schema Bus,Official Endpoint,Federated Endpoint Layer,Three-Layer Inventory

=Example Design Patterns =

The following section describes five design patterns which are utilized in SOA. The described patterns provide the problem and corresponding solution

==Canonical protocol==

[[Image:Canonicalpattern.jpg.png]]

Problem: Services that support different communication technologies compromise interoperability, limit the quantity of potential consumers, and introduce the need for undesirable protocol bridging measures.

Solution: The architecture establishes a single communications technology as the sole or primary medium by which services can interact.

From the above figure it is observed that the services are delivered by three different communication technologies A,B and C.These services are made to conform to one centralized communications technology, making them technologically compatible.with this these services can be delivered to consumers without much difficulty

==Dual protocol==

[[Image:dualprotocol.png]]

Problem: Canonical Protocol requires that all services conform to the use of the same communications technology; however, a single protocol may not be able to accommodate all service requirements, thereby introducing limitations.

Solution: The service inventory architecture is designed to support services based on primary and secondary protocols.

Regardless of protocol, all services must invoke each other via their official service contracts (A, B). Bypassing the contract may seem convenient when the underlying service logic of the primary service supports the same protocol as the secondary service (C), but it is an anti-pattern that will eventually inhibit the application of this pattern and further weaken the overall service inventory foundation.

==Protocol Bridging==

[[Image:protocolbridging.png]]

Problem: Services using different communication protocols or different versions of the same protocol cannot exchange data.

Solution: Bridging logic is introduced to enable communication between different communication protocols by dynamically converting one protocol to another at runtime.

From the above figure it can be noticed that the consumer programs interact with a middle-tier broker that provides protocol bridging features.The consumer programs may be using different protocols like [http://java.sun.com/products/jms/ JMS] or SOAP 1.1.In order to translate the two incompatible protocols in to the required SOAP 1,2 with HTTP separate protocol adapters are used in the broker. The broker then transmits the messages to the service on behalf of the consumers.Therefore the protocol bridging is achieved.

==UI Mediator==

[[Image:uimediator.png]]

Problem: Because the behavior of individual services can vary depending on their design,runtime usage, and the workload required to carry out a given capability, the consistency with which a service-oriented solution can respond to requests originating from a user-interface can fluctuate, leading to a poor user experience.

Solution: Establish mediator logic solely responsible for ensuring timely interaction and feedback with user-interfaces and presentation logic.

In this method as can be observed from the figure the three services A,B and C work behind the scenes to complete the given task.The mediator service (D) regularly updates the user interface there by hiding the underlying logic to the consumer.

==Service Facade==

[[Image:service_facade.png]]

Problem: The coupling of the core service logic to contracts and implementation resources can inhibit its evolution and negatively impact service consumers.

Solution: A service facade component is used to abstract a part of the service architecture with negative coupling potential.

Facade logic is placed in between the contract and the core service logic. This allows the core service logic to remain decoupled from the contract.The objective of loose coupling is achieved by this process.the core logic abstraction is obtained by this way.

=Similarities and Differences Between Patterns for SOA and Traditional pattens proposed by GoF=

The Gang of Four(Gof) comprising of Eric Gamma, Richard Helm, Ralph Johnson, and John Vlissides have documented the design patterns that were followed by Software developers and architects in object oriented space. They have documented 23 design patterns which are collectively called as Traditional design patterns.

The design patterns in SOA are similiar in some aspects to the traditional patterns.They also differ from the traditional patterns. The similiarities and differences between them are provided in this section

==Differences==

The differences between the SOA design patterns and traditional design patterns have been come up based on the individual functionality that each pattern provide. Following are the differences,

1) The [http://en.wikipedia.org/wiki/Composite_pattern composite pattern] organizes the objects in the manner to represent the part-whole hierarchies in a traditional two-tier hierarchy.

The [http://www.soapatterns.org/agnostic_subcontroller.asp agnostic sub-controller] implements the service composability but it differs from the composite pattern in such a way that cross-entity functionality is abstracted and made accessible through the sub –controller capability.

For instance, the traditional composite pattern has the object representing a part-whole hierarchy as in the below figure of graphic class which has draw(). If we require a cross-entity functionality as in the below figure, we require a colored rectangle, we require the functionality fill() of color class. Hence the sub-controller module is created which has the functionality of different parents, thus making it reusable.

Figure to illustrate above difference

[[Image:Composite_example.png]]

2)
The traditional [http://en.wikipedia.org/wiki/Bridge_pattern bridge pattern] separates the abstraction from its implementation in order to vary independently. Whereas the [http://www.soapatterns.org/canonical_protocol.asp canonical protocol] avoids the protocol bridging in such a way that there is a single communication technology through which the services can interact.

In the below figure of bridge pattern, the relationship between the abstraction and implementor is bridge and it results the implementor to vary independently from the abstraction by having different ConcreteImplementor. The canonical protocol avoids the variation by having a single communication technology between different objects.

Figure for above difference

[[Image:Traditional_bridge.png]]
Figure for Traditional bridge pattern

For canonical protocol refer to the explanation given in example design patterns

3) The traditional [http://en.wikipedia.org/wiki/Builder_pattern builder pattern] decouples the construction of the object from its representation so that the same construction process can be used to develop different representations. The different representations (contracts) are addressed in SOA by the [http://www.soapatterns.org/concurrent_contracts.asp Concurrent Contracts] with the application of [http://www.soapatterns.org/service_facade.asp Service-façade] design pattern. With service-façade design pattern, an abstraction is created to support the interaction between different contracts. As a result, different contracts can be created for a single service.

In the below figure, the conversion of the text document is separated from the reader of RTF document, so that the text document can be represented in different forms like ASCIIText, TeXText and TextWidget. The different representation is achieved by decoupling of construction and abstraction. In the case of concurrent contracts pattern, the different contracts or services (invoices) are created for different consumer through service-façade by creating a new abstraction.

[[Image:Builder.png]]
Figure for Traditional Builder pattern

[[Image:Concurrent_pattern.png]]
Figure for Concurrent pattern

==Similarities==
1) The [http://www.soapatterns.org/service_facade.asp Service-façade] design pattern is similar to the [http://en.wikipedia.org/wiki/Facade_pattern façade] (traditional) pattern in the manner that it implements the façade logic which is creating an abstraction for intra-communication within objects to the service architecture. The advantage by adding the façade logic to the service architecture is that it preserves the underlying logic from run-time changes.

2) The [http://www.soapatterns.org/ui_mediator.asp UI Mediator] design pattern implements the [http://en.wikipedia.org/wiki/Mediator_pattern mediator] logic of traditional mediator pattern. The mediator logic aims to provide the user responses in a way that user understands, independently of what the underlying services perform.

3) The [http://www.soapatterns.org/intermediate_routing.asp Intermediate routing] pattern in SOA is similar to [http://en.wikipedia.org/wiki/Decorator_pattern Decorator pattern] (traditional) in the functionality that it adds the required logic at run-time. The decorator adds the additional functionality to the object at run-time. The intermediate routing pattern is about placing the routing logic to address the run-time scenarios.

4)The [http://www.soapatterns.org/capability_composition.asp Capability Composition] pattern in SOA implements the [http://en.wikipedia.org/wiki/Composite_pattern Composite pattern] (traditional). The Capability Composition is about composing one or more capabilities outside the service’s context to address the large, complex problem.

5) The [http://www.soapatterns.org/decoupled_contract.asp Decoupled Contract] pattern implements the traditional [http://en.wikipedia.org/wiki/Bridge_pattern Bridge pattern] in the manner that service contract is separated from the implementation. The Bridge pattern decouples the abstraction from implementation to facilitate the variation of both (abstraction and implementation).

6) The [http://www.soapatterns.org/legacy_wrapper.asp Legacy Wrapper] pattern is related to traditional [http://en.wikipedia.org/wiki/Adapter_pattern Adapter pattern]. The Legacy Wrapper pattern protects the legacy logic by providing a standard service that takes of protecting the legacy details by encapsulating, extraction or elimination. The encapsulation, extraction or elimination is done in order to change the service as the consumer requires it. This is related to adapter in a way that it converts the interface of one class to another as the client expects.

=Summary=
The various patterns in Service oriented Architecture which have been currently proposed were studied and an attempt was made to document all of them by categories.Few detailed examples are documented to get an understanding of the underlying process.Specific comparison of design patterns in SOA domain and corresponding traditional patterns has been carried out.The design patterns in SOA are still under development and many patterns are coming up due to vast technology used in this domain.

=Glossary=

1.Serive : "A service is a discoverable resource that executes a repeatable task, and is described by an externalized service specification."

2.[http://www.ibm.com/developerworks/webservices/library/ws-soa-term1/ SOA Terminology]

3.SOA :[http://en.wikipedia.org/wiki/Service-oriented_architecture Service oriented Architecture]

4.API :[http://en.wikipedia.org/wiki/Application_programming_interface Application programming interface]

5.SOAP :[http://en.wikipedia.org/wiki/SOAP Simple Object Access Protocol]

6.HTTP :[http://en.wikipedia.org/wiki/HyperText_Transfer_Protocol Hypertext Transfer Protocol]

7.GoF :[http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Gang of Four]

8.[http://soaglossary.com/ SOA Glossory]

=References=

1.[http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Design patterns for object oriented software]

2.[http://en.wikipedia.org/wiki/Service-oriented_architecture#Introduction Service Oriented Architecture]

3.[http://www.exforsys.com/tutorials/soa/soa-definitions-and-certification.html SOA Tutorial]

4.[http://www.soapatterns.org/ soa design patterns]

5.[http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29 design pattern]

6.[http://www.oracle.com/technologies/soa/center.html oracle SOA centre]

7.[http://www.ibm.com/developerworks/webservices/library/ws-soa-term1/ IBMs SOA Contributions]

8.[http://www.oracle.com/technology/pub/articles/erl_soa_design_patterns_app_sequences.html SOA Design patterns application sequences by oracle]

9.SOA Design Patterns by Thomas Erl

CSC/ECE 517 Fall 2009/wiki2 16 rs

2009-10-10T03:11:38Z

Screenit: /* Similarities */

CSC/ECE 517 Fall 2009/wiki2 16 rs

SOA provides another view of providing functionality based upon services offered in terms of protocols and a specific API. Research and report on what patterns have been proposed and are utilized within this domain. How do they differ from traditional design patterns proposed by Eric Gamma, Richard Helm, Ralph Johnson, and John Vlissides? How are they similar?

----
=Introduction=

This article focuses on the design patterns which are proposed and utilized in the [http://en.wikipedia.org/wiki/Service_oriented_architecture Service Oriented Architecture]. As the SOA provides its services through the protocols and API, this article throws light on the design patterns that specifically provide services through protocols like [http://www.soapatterns.org/canonical_protocol.asp Canonical protocol], [http://www.soapatterns.org/dual_protocols.asp Dual protocols] and [http://www.soapatterns.org/protocol_bridging.asp Protocol Bridging]. In a broader perspective, other design patterns have been explained tersely. In addition to explanation of the SOA design patterns, this compares the SOA design patterns with the traditional design patterns proposed by the ‘Gang of Four’ (Eric Gamma, Richard Helm, Ralph Johnson, and John Vlissides) and comes up with the differences and similarities between them.

=Service Oriented Architecture-An Overview=

==SOA-Definition==

A [http://en.wikipedia.org/wiki/Service_oriented_architecture Service Oriented Architecture] is an architecture that provides collection of services. These services need to inter-operate with each other to provide the functionality. This architecture requires a loose coupling with operating systems and other technologies that form the basis of the application. The loose coupling between services is required because each interaction has to be independent of the other. The communication between services could be either simple data being passed or it could be either an activity coordinated between distinct entities or services. Some means of interoperability is required to provide the services in larger terms. Instead of defining the API, the SOA implements the interfaces using the protocols and functionality. SOA separates functions into unique entities or services, which are accessed in a network by the users to combine and reuse them to develop the applications.

==Why SOA?==

Various businesses in the field of [http://en.wikipedia.org/wiki/Information_technology Information Technology] have to justify their projects with a return on their investments. This creates a pressure in Information Technology by making it a demanding field. Information Technology needs to have requirements in a way that it has to responsive and adapt to the changing requirements.

Information Technology companies must also be able to provide the services that are compatible with other services making it interoperable, thus creating dynamic services. Moreover, Information Technology has to face demands to bring new commercial services to a much wider array of customers. Customers may access services through web interfaces, or may be part of a supply chain that needs to decrease the time and cost of manufacturing.

Thus, Information Technology companies are always on the look out for solutions that will help them meet the above demands – without having to spend a lot of money. [http://en.wikipedia.org/wiki/Service_oriented_architecture Service Oriented Architecture] offers a solution to satisfy the above needs of the industry

==SOA-Benifits==
In architectural terms, a modern architectural design should be Service Oriented, loosely coupled, driven by events, able to support both integration and assembly, aligned with valuable life cycle support processes, and able to leverage existing infrastructure and applications.

When it comes to Service Oriented Architecture, it tends to offer a variety of different advantages over more traditional methods of distributing computing. These include
i) business services across several platforms
ii) location independence
iii) authentication as well as authorization support on different platforms
iv ) loosely coupled approach, dynamic search and connectivity to other services.

=Design Patterns in SOA=
A [http://en.wikipedia.org/wiki/Design_pattern design pattern] is a general reusable solution to a commonly occurring problem in software design. A design pattern is not a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be applied in different scenarios. Design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved.

Design patterns play a major role in SOA. The implementation and deployment of SOA designs provide different challenges during product development life cycle.Such challenges may make projects to be discontinued. Design patterns help in overcoming these problems by providing a solution to the problems posed. Each SOA design pattern provides a design solution in support of
successfully applying service orientation and establishing a quality service-oriented architecture

=Design Patterns proposed =

The proposed Design Patterns for SOA fall in to following categories. They are listed below and corresponding patterns in
each category are given. Detailed explanation of the design patterns given in the example can be found in the link provided for each category.

[http://www.soapatterns.org/masterlist_c.asp#ch6 Foundational Inventory Patterns]

These design patterns focus on providing solutions to the problems like maximizing re-composition and avoiding redundant logic.

Examples include Enterprise Inventory, Domain Inventory, Service Normalization, Logic Centralization, Service Layers Canonical Protocol, Canonical Schema

[http://www.soapatterns.org/masterlist_c.asp#ch7 Logical Inventory Layer Patterns]

These design patterns provide the solution to the problem of how can business logic be separated, reused, and governed independently?

examples for this category are Utility Abstraction,Entity Abstraction,Process Abstraction

[http://www.soapatterns.org/masterlist_c.asp#ch8 Inventory Centralization Patterns]

These patterns focus on providing solution for aspect of governing business logic etc

examples for this category are Process Centralization,Schema Centralization,Policy Centralization,Rules Centralization.

[http://www.soapatterns.org/masterlist_c.asp#ch9 Inventory Implementation Patterns]

These patterns help to solve implementation problems like limitations introduced by communication technology. Example like a single protocol may not accommodate all requirements etc

examples for this category are Dual Protocols,Canonical Resources,State Repository,Stateful Services,Service Grid,Inventory Endpoint,Cross-Domain Utility Layer

[http://www.soapatterns.org/masterlist_c.asp#ch10 Inventory Governance Patterns]

The patterns deal with the governance problems caused by service contract within the same service inventory

examples for this category are Canonical Expression,Metadata Centralization,Canonical Versioning

[http://www.soapatterns.org/masterlist_c.asp#ch11 Foundational Service Patterns]

The patterns proposed in this category focus on solving large business problems without having to build a stand alone solution.

examples for this category are Functional Decomposition,Service Encapsulation,Agnostic Context,Non-Agnostic Context,Agnostic Capability

[http://www.soapatterns.org/masterlist_c.asp#ch12 Service Implementation Patterns]

The patterns in this category focus on improving the realiability and availability of the service

examples for this category are Service Facade,Redundant Implementation,Service Data Replication,Partial State Deferral,Partial Validation,UI Mediator

[http://www.soapatterns.org/masterlist_c.asp#ch13 Service Security Patterns]

The patterns proposed in this category deal with the problem of data encapsulation and security aspects.

examples for this category are Exception Shielding,Message Screening,Trusted Subsystem ,Service Perimeter Guard

[http://www.soapatterns.org/masterlist_c.asp#ch14 Service Contract Design Patterns]

The patterns proposed in this category focus on providing solution for how to make the service contract suitable for all potential customers,make it aligned with other services etc

examples for this category are Decoupled Contract,Contract Centralization,Contract De normalization,Concurrent Contracts,Validation Abstraction

[http://www.soapatterns.org/masterlist_c.asp#ch15 Legacy Encapsulation Patterns]

The patterns proposed deals with the problems in legacy systems like processing of data contained in flat files, redundancy resulting in delivery to multiple channels etc

examples for this category are Legacy Wrapper, Multi-Channel Endpoint,File Gateway

[http://www.soapatterns.org/masterlist_c.asp#ch16 Service Governance Patterns]

These patterns provide solution for problems like updating the customers with changed service so that they are not affected, modifications in service etc

examples for this category are Compatible Change,Version Identification,Termination Notification,Service Refactoring,Service Decomposition,Proxy Capability,Decomposed Capability,Distributed Capability

[http://www.soapatterns.org/masterlist_c.asp#ch17 Capability Composition Patterns]

The pattern proposed focuses on the problem of How can a service capability solve a problem that requires logic outside of the service boundary and How can the same capability be used to help solve multiple problems?

examples for this category are Capability Composition,Capability Recomposition

[http://www.soapatterns.org/masterlist_c.asp#ch18 Service Messaging Patterns]

The patterns proposed in this category focus on setting up of message framework for transfer of data.

examples in this category are Service Messaging,Messaging Metadata,Service Agent,Intermediate Routing,State Messaging,Service Callback,Service Instance Routing,Asynchronous Queuing,Reliable Messaging,Event-Driven Messaging.

[http://www.soapatterns.org/masterlist_c.asp#ch19 Composition Implementation Patterns]

The patterns proposed in this category focus on problems during runtime like runtime activities that span multiple services fail, the parent business task is incomplete etc

examples for this category are Agnostic SubController,Composition Autonomy,Atomic Service Transaction,Compensating ServiceTransaction

[http://www.soapatterns.org/masterlist_c.asp#ch20 Service Interaction Security Patterns]

The proposed patterns in this category are focused on security methods like encryption,decryption,authenticating the data,consumer and service

examples for this category are Data Confidentiality, Data Origin Authentication, Direct Authentication, Brokered Authentication

[http://www.soapatterns.org/masterlist_c.asp#ch21 Transformation Patterns]

The Patterns proposed in this category concrete on how data from one data model can be dynamically converted to comply to a different data model.

examples for this category are Data Model Transformation,Data Format Transformation, Protocol Bridging

[http://www.soapatterns.org/masterlist_c.asp#ch22 Common Compound Design Patterns]

A compound pattern is a coarse-grained pattern comprised of a set of finer-grained patterns.

examples for this category are Orchestration,Enterprise Service Bus,Service Broker,Canonical Schema Bus,Official Endpoint,Federated Endpoint Layer,Three-Layer Inventory

=Example Design Patterns =

The following section describes five design patterns which are utilized in SOA. The described patterns provide the problem and corresponding solution

==Canonical protocol==

[[Image:Canonicalpattern.jpg.png]]

Problem: Services that support different communication technologies compromise interoperability, limit the quantity of potential consumers, and introduce the need for undesirable protocol bridging measures.

Solution: The architecture establishes a single communications technology as the sole or primary medium by which services can interact.

From the above figure it is observed that the services are delivered by three different communication technologies A,B and C.These services are made to conform to one centralized communications technology, making them technologically compatible.with this these services can be delivered to consumers without much difficulty

==Dual protocol==

[[Image:dualprotocol.png]]

Problem: Canonical Protocol requires that all services conform to the use of the same communications technology; however, a single protocol may not be able to accommodate all service requirements, thereby introducing limitations.

Solution: The service inventory architecture is designed to support services based on primary and secondary protocols.

Regardless of protocol, all services must invoke each other via their official service contracts (A, B). Bypassing the contract may seem convenient when the underlying service logic of the primary service supports the same protocol as the secondary service (C), but it is an anti-pattern that will eventually inhibit the application of this pattern and further weaken the overall service inventory foundation.

==Protocol Bridging==

[[Image:protocolbridging.png]]

Problem: Services using different communication protocols or different versions of the same protocol cannot exchange data.

Solution: Bridging logic is introduced to enable communication between different communication protocols by dynamically converting one protocol to another at runtime.

From the above figure it can be noticed that the consumer programs interact with a middle-tier broker that provides protocol bridging features.The consumer programs may be using different protocols like [http://java.sun.com/products/jms/ JMS] or SOAP 1.1.In order to translate the two incompatible protocols in to the required SOAP 1,2 with HTTP separate protocol adapters are used in the broker. The broker then transmits the messages to the service on behalf of the consumers.Therefore the protocol bridging is achieved.

==UI Mediator==

[[Image:uimediator.png]]

Problem: Because the behavior of individual services can vary depending on their design,runtime usage, and the workload required to carry out a given capability, the consistency with which a service-oriented solution can respond to requests originating from a user-interface can fluctuate, leading to a poor user experience.

Solution: Establish mediator logic solely responsible for ensuring timely interaction and feedback with user-interfaces and presentation logic.

In this method as can be observed from the figure the three services A,B and C work behind the scenes to complete the given task.The mediator service (D) regularly updates the user interface there by hiding the underlying logic to the consumer.

==Service Facade==

[[Image:service_facade.png]]

Problem: The coupling of the core service logic to contracts and implementation resources can inhibit its evolution and negatively impact service consumers.

Solution: A service facade component is used to abstract a part of the service architecture with negative coupling potential.

Facade logic is placed in between the contract and the core service logic. This allows the core service logic to remain decoupled from the contract.The objective of loose coupling is achieved by this process.the core logic abstraction is obtained by this way.

=Similarities and Differences Between Patterns for SOA and Traditional pattens proposed by GoF=

The Gang of Four(Gof) comprising of Eric Gamma, Richard Helm, Ralph Johnson, and John Vlissides have documented the design patterns that were followed by Software developers and architects in object oriented space. They have documented 23 design patterns which are collectively called as Traditional design patterns.

The design patterns in SOA are similiar in some aspects to the traditional patterns.They also differ from the traditional patterns. The similiarities and differences between them are provided in this section

==Differences==

The differences between the SOA design patterns and traditional design patterns have been come up based on the individual functionality that each pattern provide. Following are the differences,

1) The [http://en.wikipedia.org/wiki/Composite_pattern composite pattern] organizes the objects in the manner to represent the part-whole hierarchies in a traditional two-tier hierarchy.

The [http://www.soapatterns.org/agnostic_subcontroller.asp agnostic sub-controller] implements the service composability but it differs from the composite pattern in such a way that cross-entity functionality is abstracted and made accessible through the sub –controller capability.

For instance, the traditional composite pattern has the object representing a part-whole hierarchy as in the below figure of graphic class which has draw(). If we require a cross-entity functionality as in the below figure, we require a colored rectangle, we require the functionality fill() of color class. Hence the sub-controller module is created which has the functionality of different parents, thus making it reusable.

Figure to illustrate above difference

[[Image:Composite_example.png]]

2)
The traditional [http://en.wikipedia.org/wiki/Bridge_pattern bridge pattern] separates the abstraction from its implementation in order to vary independently. Whereas the [http://www.soapatterns.org/canonical_protocol.asp canonical protocol] avoids the protocol bridging in such a way that there is a single communication technology through which the services can interact.

In the below figure of bridge pattern, the relationship between the abstraction and implementor is bridge and it results the implementor to vary independently from the abstraction by having different ConcreteImplementor. The canonical protocol avoids the variation by having a single communication technology between different objects.

Figure for above difference

[[Image:Traditional_bridge.png]]
Figure for Traditional bridge pattern

For canonical protocol refer to the explanation given in example design patterns

3) The traditional [http://en.wikipedia.org/wiki/Builder_pattern builder pattern] decouples the construction of the object from its representation so that the same construction process can be used to develop different representations. The different representations (contracts) are addressed in SOA by the [http://www.soapatterns.org/concurrent_contracts.asp Concurrent Contracts] with the application of [http://www.soapatterns.org/service_facade.asp Service-façade] design pattern. With service-façade design pattern, an abstraction is created to support the interaction between different contracts. As a result, different contracts can be created for a single service.

In the below figure, the conversion of the text document is separated from the reader of RTF document, so that the text document can be represented in different forms like ASCIIText, TeXText and TextWidget. The different representation is achieved by decoupling of construction and abstraction. In the case of concurrent contracts pattern, the different contracts or services (invoices) are created for different consumer through service-façade by creating a new abstraction.

[[Image:Builder.png]]
Figure for Traditional Builder pattern

[[Image:Concurrent_pattern.png]]
Figure for Concurrent pattern

==Similarities==
1) The [http://www.soapatterns.org/service_facade.asp Service-façade] design pattern is similar to the [http://en.wikipedia.org/wiki/Facade_pattern façade] (traditional) pattern in the manner that it implements the façade logic which is creating an abstraction for intra-communication within objects to the service architecture. The advantage by adding the façade logic to the service architecture is that it preserves the underlying logic from run-time changes.

2) The [http://www.soapatterns.org/ui_mediator.asp UI Mediator] design pattern implements the [http://en.wikipedia.org/wiki/Mediator_pattern mediator] logic of traditional mediator pattern. The mediator logic aims to provide the user responses in a way that user understands, independently of what the underlying services perform.

3) The [http://www.soapatterns.org/intermediate_routing.asp Intermediate routing] pattern in SOA is similar to [http://en.wikipedia.org/wiki/Decorator_pattern Decorator pattern] (traditional) in the functionality that it adds the required logic at run-time. The decorator adds the additional functionality to the object at run-time. The intermediate routing pattern is about placing the routing logic to address the run-time scenarios.

4)The [http://www.soapatterns.org/capability_composition.asp Capability Composition] pattern in SOA implements the [http://en.wikipedia.org/wiki/Composite_pattern Composite pattern] (traditional). The Capability Composition is about composing one or more capabilities outside the service’s context to address the large, complex problem.

5) The [http://www.soapatterns.org/decoupled_contract.asp Decoupled Contract] pattern implements the traditional [http://en.wikipedia.org/wiki/Bridge_pattern Bridge pattern] in the manner that service contract is separated from the implementation. The Bridge pattern decouples the abstraction from implementation to facilitate the variation of both (abstraction and implementation).

6) The [http://www.soapatterns.org/legacy_wrapper.asp Legacy Wrapper] pattern is related to traditional [http://en.wikipedia.org/wiki/Adapter_pattern Adapter pattern]. The Legacy Wrapper pattern protects the legacy logic by providing a standard service that takes of protecting the legacy details by encapsulating, extraction or elimination. The encapsulation, extraction or elimination is done in order to change the service as the consumer requires it. This is related to adapter in a way that it converts the interface of one class to another as the client expects.

=Summary=
The various patterns in Service oriented Architecture which have been currently proposed were studied and an attempt was made to document all of them by categories.Few detailed examples are documented to get an understanding of the underlying process.Specific comparison of design patterns in SOA domain and corresponding traditional patterns has been carried out.The design patterns in SOA are still under development and many patterns are coming up due to vast technology used in this domain.

=Glossary=

1.Serive : "A service is a discoverable resource that executes a repeatable task, and is described by an externalized service specification."

2.[http://www.ibm.com/developerworks/webservices/library/ws-soa-term1/ SOA Terminology]

3.SOA :[http://en.wikipedia.org/wiki/Service-oriented_architecture Service oriented Architecture]

4.API :[http://en.wikipedia.org/wiki/Application_programming_interface Application programming interface]

5.SOAP :[http://en.wikipedia.org/wiki/SOAP Simple Object Access Protocol]

6.HTTP :[http://en.wikipedia.org/wiki/HyperText_Transfer_Protocol Hypertext Transfer Protocol]

7.GoF :[http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Gang of Four]

8.[http://soaglossary.com/ SOA Glossory]

=References=

1.[http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Design patterns for object oriented software]

2.[http://en.wikipedia.org/wiki/Service-oriented_architecture#Introduction Service Oriented Architecture]

3.[http://www.exforsys.com/tutorials/soa/soa-definitions-and-certification.html SOA Tutorial]

4.[http://www.soapatterns.org/ soa design patterns]

5.[http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29 design pattern]

6.[http://www.oracle.com/technologies/soa/center.html oracle SOA centre]

7.[http://www.ibm.com/developerworks/webservices/library/ws-soa-term1/ IBMs SOA Contributions]

8.[http://www.oracle.com/technology/pub/articles/erl_soa_design_patterns_app_sequences.html SOA Design patterns application sequences by oracle]

CSC/ECE 517 Fall 2009/wiki2 16 rs

2009-10-10T03:04:30Z

Screenit: /* Differences */

CSC/ECE 517 Fall 2009/wiki2 16 rs

SOA provides another view of providing functionality based upon services offered in terms of protocols and a specific API. Research and report on what patterns have been proposed and are utilized within this domain. How do they differ from traditional design patterns proposed by Eric Gamma, Richard Helm, Ralph Johnson, and John Vlissides? How are they similar?

----
=Introduction=

This article focuses on the design patterns which are proposed and utilized in the [http://en.wikipedia.org/wiki/Service_oriented_architecture Service Oriented Architecture]. As the SOA provides its services through the protocols and API, this article throws light on the design patterns that specifically provide services through protocols like [http://www.soapatterns.org/canonical_protocol.asp Canonical protocol], [http://www.soapatterns.org/dual_protocols.asp Dual protocols] and [http://www.soapatterns.org/protocol_bridging.asp Protocol Bridging]. In a broader perspective, other design patterns have been explained tersely. In addition to explanation of the SOA design patterns, this compares the SOA design patterns with the traditional design patterns proposed by the ‘Gang of Four’ (Eric Gamma, Richard Helm, Ralph Johnson, and John Vlissides) and comes up with the differences and similarities between them.

=Service Oriented Architecture-An Overview=

==SOA-Definition==

A [http://en.wikipedia.org/wiki/Service_oriented_architecture Service Oriented Architecture] is an architecture that provides collection of services. These services need to inter-operate with each other to provide the functionality. This architecture requires a loose coupling with operating systems and other technologies that form the basis of the application. The loose coupling between services is required because each interaction has to be independent of the other. The communication between services could be either simple data being passed or it could be either an activity coordinated between distinct entities or services. Some means of interoperability is required to provide the services in larger terms. Instead of defining the API, the SOA implements the interfaces using the protocols and functionality. SOA separates functions into unique entities or services, which are accessed in a network by the users to combine and reuse them to develop the applications.

==Why SOA?==

Various businesses in the field of [http://en.wikipedia.org/wiki/Information_technology Information Technology] have to justify their projects with a return on their investments. This creates a pressure in Information Technology by making it a demanding field. Information Technology needs to have requirements in a way that it has to responsive and adapt to the changing requirements.

Information Technology companies must also be able to provide the services that are compatible with other services making it interoperable, thus creating dynamic services. Moreover, Information Technology has to face demands to bring new commercial services to a much wider array of customers. Customers may access services through web interfaces, or may be part of a supply chain that needs to decrease the time and cost of manufacturing.

Thus, Information Technology companies are always on the look out for solutions that will help them meet the above demands – without having to spend a lot of money. [http://en.wikipedia.org/wiki/Service_oriented_architecture Service Oriented Architecture] offers a solution to satisfy the above needs of the industry

==SOA-Benifits==
In architectural terms, a modern architectural design should be Service Oriented, loosely coupled, driven by events, able to support both integration and assembly, aligned with valuable life cycle support processes, and able to leverage existing infrastructure and applications.

When it comes to Service Oriented Architecture, it tends to offer a variety of different advantages over more traditional methods of distributing computing. These include
i) business services across several platforms
ii) location independence
iii) authentication as well as authorization support on different platforms
iv ) loosely coupled approach, dynamic search and connectivity to other services.

=Design Patterns in SOA=
A [http://en.wikipedia.org/wiki/Design_pattern design pattern] is a general reusable solution to a commonly occurring problem in software design. A design pattern is not a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be applied in different scenarios. Design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved.

Design patterns play a major role in SOA. The implementation and deployment of SOA designs provide different challenges during product development life cycle.Such challenges may make projects to be discontinued. Design patterns help in overcoming these problems by providing a solution to the problems posed. Each SOA design pattern provides a design solution in support of
successfully applying service orientation and establishing a quality service-oriented architecture

=Design Patterns proposed =

The proposed Design Patterns for SOA fall in to following categories. They are listed below and corresponding patterns in
each category are given. Detailed explanation of the design patterns given in the example can be found in the link provided for each category.

[http://www.soapatterns.org/masterlist_c.asp#ch6 Foundational Inventory Patterns]

These design patterns focus on providing solutions to the problems like maximizing re-composition and avoiding redundant logic.

Examples include Enterprise Inventory, Domain Inventory, Service Normalization, Logic Centralization, Service Layers Canonical Protocol, Canonical Schema

[http://www.soapatterns.org/masterlist_c.asp#ch7 Logical Inventory Layer Patterns]

These design patterns provide the solution to the problem of how can business logic be separated, reused, and governed independently?

examples for this category are Utility Abstraction,Entity Abstraction,Process Abstraction

[http://www.soapatterns.org/masterlist_c.asp#ch8 Inventory Centralization Patterns]

These patterns focus on providing solution for aspect of governing business logic etc

examples for this category are Process Centralization,Schema Centralization,Policy Centralization,Rules Centralization.

[http://www.soapatterns.org/masterlist_c.asp#ch9 Inventory Implementation Patterns]

These patterns help to solve implementation problems like limitations introduced by communication technology. Example like a single protocol may not accommodate all requirements etc

examples for this category are Dual Protocols,Canonical Resources,State Repository,Stateful Services,Service Grid,Inventory Endpoint,Cross-Domain Utility Layer

[http://www.soapatterns.org/masterlist_c.asp#ch10 Inventory Governance Patterns]

The patterns deal with the governance problems caused by service contract within the same service inventory

examples for this category are Canonical Expression,Metadata Centralization,Canonical Versioning

[http://www.soapatterns.org/masterlist_c.asp#ch11 Foundational Service Patterns]

The patterns proposed in this category focus on solving large business problems without having to build a stand alone solution.

examples for this category are Functional Decomposition,Service Encapsulation,Agnostic Context,Non-Agnostic Context,Agnostic Capability

[http://www.soapatterns.org/masterlist_c.asp#ch12 Service Implementation Patterns]

The patterns in this category focus on improving the realiability and availability of the service

examples for this category are Service Facade,Redundant Implementation,Service Data Replication,Partial State Deferral,Partial Validation,UI Mediator

[http://www.soapatterns.org/masterlist_c.asp#ch13 Service Security Patterns]

The patterns proposed in this category deal with the problem of data encapsulation and security aspects.

examples for this category are Exception Shielding,Message Screening,Trusted Subsystem ,Service Perimeter Guard

[http://www.soapatterns.org/masterlist_c.asp#ch14 Service Contract Design Patterns]

The patterns proposed in this category focus on providing solution for how to make the service contract suitable for all potential customers,make it aligned with other services etc

examples for this category are Decoupled Contract,Contract Centralization,Contract De normalization,Concurrent Contracts,Validation Abstraction

[http://www.soapatterns.org/masterlist_c.asp#ch15 Legacy Encapsulation Patterns]

The patterns proposed deals with the problems in legacy systems like processing of data contained in flat files, redundancy resulting in delivery to multiple channels etc

examples for this category are Legacy Wrapper, Multi-Channel Endpoint,File Gateway

[http://www.soapatterns.org/masterlist_c.asp#ch16 Service Governance Patterns]

These patterns provide solution for problems like updating the customers with changed service so that they are not affected, modifications in service etc

examples for this category are Compatible Change,Version Identification,Termination Notification,Service Refactoring,Service Decomposition,Proxy Capability,Decomposed Capability,Distributed Capability

[http://www.soapatterns.org/masterlist_c.asp#ch17 Capability Composition Patterns]

The pattern proposed focuses on the problem of How can a service capability solve a problem that requires logic outside of the service boundary and How can the same capability be used to help solve multiple problems?

examples for this category are Capability Composition,Capability Recomposition

[http://www.soapatterns.org/masterlist_c.asp#ch18 Service Messaging Patterns]

The patterns proposed in this category focus on setting up of message framework for transfer of data.

examples in this category are Service Messaging,Messaging Metadata,Service Agent,Intermediate Routing,State Messaging,Service Callback,Service Instance Routing,Asynchronous Queuing,Reliable Messaging,Event-Driven Messaging.

[http://www.soapatterns.org/masterlist_c.asp#ch19 Composition Implementation Patterns]

The patterns proposed in this category focus on problems during runtime like runtime activities that span multiple services fail, the parent business task is incomplete etc

examples for this category are Agnostic SubController,Composition Autonomy,Atomic Service Transaction,Compensating ServiceTransaction

[http://www.soapatterns.org/masterlist_c.asp#ch20 Service Interaction Security Patterns]

The proposed patterns in this category are focused on security methods like encryption,decryption,authenticating the data,consumer and service

examples for this category are Data Confidentiality, Data Origin Authentication, Direct Authentication, Brokered Authentication

[http://www.soapatterns.org/masterlist_c.asp#ch21 Transformation Patterns]

The Patterns proposed in this category concrete on how data from one data model can be dynamically converted to comply to a different data model.

examples for this category are Data Model Transformation,Data Format Transformation, Protocol Bridging

[http://www.soapatterns.org/masterlist_c.asp#ch22 Common Compound Design Patterns]

A compound pattern is a coarse-grained pattern comprised of a set of finer-grained patterns.

examples for this category are Orchestration,Enterprise Service Bus,Service Broker,Canonical Schema Bus,Official Endpoint,Federated Endpoint Layer,Three-Layer Inventory

=Example Design Patterns =

The following section describes five design patterns which are utilized in SOA. The described patterns provide the problem and corresponding solution

==Canonical protocol==

[[Image:Canonicalpattern.jpg.png]]

Problem: Services that support different communication technologies compromise interoperability, limit the quantity of potential consumers, and introduce the need for undesirable protocol bridging measures.

Solution: The architecture establishes a single communications technology as the sole or primary medium by which services can interact.

From the above figure it is observed that the services are delivered by three different communication technologies A,B and C.These services are made to conform to one centralized communications technology, making them technologically compatible.with this these services can be delivered to consumers without much difficulty

==Dual protocol==

[[Image:dualprotocol.png]]

Problem: Canonical Protocol requires that all services conform to the use of the same communications technology; however, a single protocol may not be able to accommodate all service requirements, thereby introducing limitations.

Solution: The service inventory architecture is designed to support services based on primary and secondary protocols.

Regardless of protocol, all services must invoke each other via their official service contracts (A, B). Bypassing the contract may seem convenient when the underlying service logic of the primary service supports the same protocol as the secondary service (C), but it is an anti-pattern that will eventually inhibit the application of this pattern and further weaken the overall service inventory foundation.

==Protocol Bridging==

[[Image:protocolbridging.png]]

Problem: Services using different communication protocols or different versions of the same protocol cannot exchange data.

Solution: Bridging logic is introduced to enable communication between different communication protocols by dynamically converting one protocol to another at runtime.

From the above figure it can be noticed that the consumer programs interact with a middle-tier broker that provides protocol bridging features.The consumer programs may be using different protocols like [http://java.sun.com/products/jms/ JMS] or SOAP 1.1.In order to translate the two incompatible protocols in to the required SOAP 1,2 with HTTP separate protocol adapters are used in the broker. The broker then transmits the messages to the service on behalf of the consumers.Therefore the protocol bridging is achieved.

==UI Mediator==

[[Image:uimediator.png]]

Problem: Because the behavior of individual services can vary depending on their design,runtime usage, and the workload required to carry out a given capability, the consistency with which a service-oriented solution can respond to requests originating from a user-interface can fluctuate, leading to a poor user experience.

Solution: Establish mediator logic solely responsible for ensuring timely interaction and feedback with user-interfaces and presentation logic.

In this method as can be observed from the figure the three services A,B and C work behind the scenes to complete the given task.The mediator service (D) regularly updates the user interface there by hiding the underlying logic to the consumer.

==Service Facade==

[[Image:service_facade.png]]

Problem: The coupling of the core service logic to contracts and implementation resources can inhibit its evolution and negatively impact service consumers.

Solution: A service facade component is used to abstract a part of the service architecture with negative coupling potential.

Facade logic is placed in between the contract and the core service logic. This allows the core service logic to remain decoupled from the contract.The objective of loose coupling is achieved by this process.the core logic abstraction is obtained by this way.

=Similarities and Differences Between Patterns for SOA and Traditional pattens proposed by GoF=

The Gang of Four(Gof) comprising of Eric Gamma, Richard Helm, Ralph Johnson, and John Vlissides have documented the design patterns that were followed by Software developers and architects in object oriented space. They have documented 23 design patterns which are collectively called as Traditional design patterns.

The design patterns in SOA are similiar in some aspects to the traditional patterns.They also differ from the traditional patterns. The similiarities and differences between them are provided in this section

==Differences==

The differences between the SOA design patterns and traditional design patterns have been come up based on the individual functionality that each pattern provide. Following are the differences,

1) The [http://en.wikipedia.org/wiki/Composite_pattern composite pattern] organizes the objects in the manner to represent the part-whole hierarchies in a traditional two-tier hierarchy.

The [http://www.soapatterns.org/agnostic_subcontroller.asp agnostic sub-controller] implements the service composability but it differs from the composite pattern in such a way that cross-entity functionality is abstracted and made accessible through the sub –controller capability.

For instance, the traditional composite pattern has the object representing a part-whole hierarchy as in the below figure of graphic class which has draw(). If we require a cross-entity functionality as in the below figure, we require a colored rectangle, we require the functionality fill() of color class. Hence the sub-controller module is created which has the functionality of different parents, thus making it reusable.

Figure to illustrate above difference

[[Image:Composite_example.png]]

2)
The traditional [http://en.wikipedia.org/wiki/Bridge_pattern bridge pattern] separates the abstraction from its implementation in order to vary independently. Whereas the [http://www.soapatterns.org/canonical_protocol.asp canonical protocol] avoids the protocol bridging in such a way that there is a single communication technology through which the services can interact.

In the below figure of bridge pattern, the relationship between the abstraction and implementor is bridge and it results the implementor to vary independently from the abstraction by having different ConcreteImplementor. The canonical protocol avoids the variation by having a single communication technology between different objects.

Figure for above difference

[[Image:Traditional_bridge.png]]
Figure for Traditional bridge pattern

For canonical protocol refer to the explanation given in example design patterns

3) The traditional [http://en.wikipedia.org/wiki/Builder_pattern builder pattern] decouples the construction of the object from its representation so that the same construction process can be used to develop different representations. The different representations (contracts) are addressed in SOA by the [http://www.soapatterns.org/concurrent_contracts.asp Concurrent Contracts] with the application of [http://www.soapatterns.org/service_facade.asp Service-façade] design pattern. With service-façade design pattern, an abstraction is created to support the interaction between different contracts. As a result, different contracts can be created for a single service.

In the below figure, the conversion of the text document is separated from the reader of RTF document, so that the text document can be represented in different forms like ASCIIText, TeXText and TextWidget. The different representation is achieved by decoupling of construction and abstraction. In the case of concurrent contracts pattern, the different contracts or services (invoices) are created for different consumer through service-façade by creating a new abstraction.

[[Image:Builder.png]]
Figure for Traditional Builder pattern

[[Image:Concurrent_pattern.png]]
Figure for Concurrent pattern

==Similarities==
1) The Service-façade design pattern is similar to the façade (traditional) pattern in the manner that it implements the façade logic which is creating an abstraction for intra-communication within objects to the service architecture. The advantage by adding the façade logic to the service architecture is that it preserves the underlying logic from run-time changes.

2) The UI Mediator design pattern implements the mediator logic of traditional mediator pattern. The mediator logic aims to provide the user responses in a way that user understands, independently of what the underlying services perform.

3) The Intermediate routing pattern in SOA is similar to Decorator pattern (traditional) in the functionality that it adds the required logic at run-time. The decorator adds the additional functionality to the object at run-time. The intermediate routing pattern is about placing the routing logic to address the run-time scenarios.

4)The Capability Composition pattern in SOA implements the Composite pattern (traditional). The Capability Composition is about composing one or more capabilities outside the service’s context to address the large, complex problem.

5) The Decoupled Contract pattern implements the traditional Bridge pattern in the manner that service contract is separated from the implementation. The Bridge pattern decouples the abstraction from implementation to facilitate the variation of both (abstraction and implementation).

6) The Legacy Wrapper pattern is related to traditional Adapter pattern. The Legacy Wrapper pattern protects the legacy logic by providing a standard service that takes of protecting the legacy details by encapsulating, extraction or elimination. The encapsulation, extraction or elimination is done in order to change the service as the consumer requires it. This is related to adapter in a way that it converts the interface of one class to another as the client expects.

=Summary=

=Glossary=

1.Serive : "A service is a discoverable resource that executes a repeatable task, and is described by an externalized service specification."

2.[http://www.ibm.com/developerworks/webservices/library/ws-soa-term1/ SOA Terminology]

3.SOA :[http://en.wikipedia.org/wiki/Service-oriented_architecture Service oriented Architecture]

4.API :[http://en.wikipedia.org/wiki/Application_programming_interface Application programming interface]

5.SOAP :[http://en.wikipedia.org/wiki/SOAP Simple Object Access Protocol]

6.HTTP :[http://en.wikipedia.org/wiki/HyperText_Transfer_Protocol Hypertext Transfer Protocol]

7.GoF :[http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Gang of Four]

8.[http://soaglossary.com/ SOA Glossory]

=References=

1.[http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Design patterns for object oriented software]

2.[http://en.wikipedia.org/wiki/Service-oriented_architecture#Introduction Service Oriented Architecture]

3.[http://www.exforsys.com/tutorials/soa/soa-definitions-and-certification.html SOA Tutorial]

4.[http://www.soapatterns.org/ soa design patterns]

5.[http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29 design pattern]

6.[http://www.oracle.com/technologies/soa/center.html oracle SOA centre]

7.[http://www.ibm.com/developerworks/webservices/library/ws-soa-term1/ IBMs SOA Contributions]

8.[http://www.oracle.com/technology/pub/articles/erl_soa_design_patterns_app_sequences.html SOA Design patterns application sequences by oracle]

CSC/ECE 517 Fall 2009/wiki2 16 rs

2009-10-10T02:56:45Z

Screenit: /* Example Design Patterns */

CSC/ECE 517 Fall 2009/wiki2 16 rs

SOA provides another view of providing functionality based upon services offered in terms of protocols and a specific API. Research and report on what patterns have been proposed and are utilized within this domain. How do they differ from traditional design patterns proposed by Eric Gamma, Richard Helm, Ralph Johnson, and John Vlissides? How are they similar?

----
=Introduction=

This article focuses on the design patterns which are proposed and utilized in the [http://en.wikipedia.org/wiki/Service_oriented_architecture Service Oriented Architecture]. As the SOA provides its services through the protocols and API, this article throws light on the design patterns that specifically provide services through protocols like [http://www.soapatterns.org/canonical_protocol.asp Canonical protocol], [http://www.soapatterns.org/dual_protocols.asp Dual protocols] and [http://www.soapatterns.org/protocol_bridging.asp Protocol Bridging]. In a broader perspective, other design patterns have been explained tersely. In addition to explanation of the SOA design patterns, this compares the SOA design patterns with the traditional design patterns proposed by the ‘Gang of Four’ (Eric Gamma, Richard Helm, Ralph Johnson, and John Vlissides) and comes up with the differences and similarities between them.

=Service Oriented Architecture-An Overview=

==SOA-Definition==

A [http://en.wikipedia.org/wiki/Service_oriented_architecture Service Oriented Architecture] is an architecture that provides collection of services. These services need to inter-operate with each other to provide the functionality. This architecture requires a loose coupling with operating systems and other technologies that form the basis of the application. The loose coupling between services is required because each interaction has to be independent of the other. The communication between services could be either simple data being passed or it could be either an activity coordinated between distinct entities or services. Some means of interoperability is required to provide the services in larger terms. Instead of defining the API, the SOA implements the interfaces using the protocols and functionality. SOA separates functions into unique entities or services, which are accessed in a network by the users to combine and reuse them to develop the applications.

==Why SOA?==

Various businesses in the field of [http://en.wikipedia.org/wiki/Information_technology Information Technology] have to justify their projects with a return on their investments. This creates a pressure in Information Technology by making it a demanding field. Information Technology needs to have requirements in a way that it has to responsive and adapt to the changing requirements.

Information Technology companies must also be able to provide the services that are compatible with other services making it interoperable, thus creating dynamic services. Moreover, Information Technology has to face demands to bring new commercial services to a much wider array of customers. Customers may access services through web interfaces, or may be part of a supply chain that needs to decrease the time and cost of manufacturing.

Thus, Information Technology companies are always on the look out for solutions that will help them meet the above demands – without having to spend a lot of money. [http://en.wikipedia.org/wiki/Service_oriented_architecture Service Oriented Architecture] offers a solution to satisfy the above needs of the industry

==SOA-Benifits==
In architectural terms, a modern architectural design should be Service Oriented, loosely coupled, driven by events, able to support both integration and assembly, aligned with valuable life cycle support processes, and able to leverage existing infrastructure and applications.

When it comes to Service Oriented Architecture, it tends to offer a variety of different advantages over more traditional methods of distributing computing. These include
i) business services across several platforms
ii) location independence
iii) authentication as well as authorization support on different platforms
iv ) loosely coupled approach, dynamic search and connectivity to other services.

=Design Patterns in SOA=
A [http://en.wikipedia.org/wiki/Design_pattern design pattern] is a general reusable solution to a commonly occurring problem in software design. A design pattern is not a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be applied in different scenarios. Design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved.

Design patterns play a major role in SOA. The implementation and deployment of SOA designs provide different challenges during product development life cycle.Such challenges may make projects to be discontinued. Design patterns help in overcoming these problems by providing a solution to the problems posed. Each SOA design pattern provides a design solution in support of
successfully applying service orientation and establishing a quality service-oriented architecture

=Design Patterns proposed =

The proposed Design Patterns for SOA fall in to following categories. They are listed below and corresponding patterns in
each category are given. Detailed explanation of the design patterns given in the example can be found in the link provided for each category.

[http://www.soapatterns.org/masterlist_c.asp#ch6 Foundational Inventory Patterns]

These design patterns focus on providing solutions to the problems like maximizing re-composition and avoiding redundant logic.

Examples include Enterprise Inventory, Domain Inventory, Service Normalization, Logic Centralization, Service Layers Canonical Protocol, Canonical Schema

[http://www.soapatterns.org/masterlist_c.asp#ch7 Logical Inventory Layer Patterns]

These design patterns provide the solution to the problem of how can business logic be separated, reused, and governed independently?

examples for this category are Utility Abstraction,Entity Abstraction,Process Abstraction

[http://www.soapatterns.org/masterlist_c.asp#ch8 Inventory Centralization Patterns]

These patterns focus on providing solution for aspect of governing business logic etc

examples for this category are Process Centralization,Schema Centralization,Policy Centralization,Rules Centralization.

[http://www.soapatterns.org/masterlist_c.asp#ch9 Inventory Implementation Patterns]

These patterns help to solve implementation problems like limitations introduced by communication technology. Example like a single protocol may not accommodate all requirements etc

examples for this category are Dual Protocols,Canonical Resources,State Repository,Stateful Services,Service Grid,Inventory Endpoint,Cross-Domain Utility Layer

[http://www.soapatterns.org/masterlist_c.asp#ch10 Inventory Governance Patterns]

The patterns deal with the governance problems caused by service contract within the same service inventory

examples for this category are Canonical Expression,Metadata Centralization,Canonical Versioning

[http://www.soapatterns.org/masterlist_c.asp#ch11 Foundational Service Patterns]

The patterns proposed in this category focus on solving large business problems without having to build a stand alone solution.

examples for this category are Functional Decomposition,Service Encapsulation,Agnostic Context,Non-Agnostic Context,Agnostic Capability

[http://www.soapatterns.org/masterlist_c.asp#ch12 Service Implementation Patterns]

The patterns in this category focus on improving the realiability and availability of the service

examples for this category are Service Facade,Redundant Implementation,Service Data Replication,Partial State Deferral,Partial Validation,UI Mediator

[http://www.soapatterns.org/masterlist_c.asp#ch13 Service Security Patterns]

The patterns proposed in this category deal with the problem of data encapsulation and security aspects.

examples for this category are Exception Shielding,Message Screening,Trusted Subsystem ,Service Perimeter Guard

[http://www.soapatterns.org/masterlist_c.asp#ch14 Service Contract Design Patterns]

The patterns proposed in this category focus on providing solution for how to make the service contract suitable for all potential customers,make it aligned with other services etc

examples for this category are Decoupled Contract,Contract Centralization,Contract De normalization,Concurrent Contracts,Validation Abstraction

[http://www.soapatterns.org/masterlist_c.asp#ch15 Legacy Encapsulation Patterns]

The patterns proposed deals with the problems in legacy systems like processing of data contained in flat files, redundancy resulting in delivery to multiple channels etc

examples for this category are Legacy Wrapper, Multi-Channel Endpoint,File Gateway

[http://www.soapatterns.org/masterlist_c.asp#ch16 Service Governance Patterns]

These patterns provide solution for problems like updating the customers with changed service so that they are not affected, modifications in service etc

examples for this category are Compatible Change,Version Identification,Termination Notification,Service Refactoring,Service Decomposition,Proxy Capability,Decomposed Capability,Distributed Capability

[http://www.soapatterns.org/masterlist_c.asp#ch17 Capability Composition Patterns]

The pattern proposed focuses on the problem of How can a service capability solve a problem that requires logic outside of the service boundary and How can the same capability be used to help solve multiple problems?

examples for this category are Capability Composition,Capability Recomposition

[http://www.soapatterns.org/masterlist_c.asp#ch18 Service Messaging Patterns]

The patterns proposed in this category focus on setting up of message framework for transfer of data.

examples in this category are Service Messaging,Messaging Metadata,Service Agent,Intermediate Routing,State Messaging,Service Callback,Service Instance Routing,Asynchronous Queuing,Reliable Messaging,Event-Driven Messaging.

[http://www.soapatterns.org/masterlist_c.asp#ch19 Composition Implementation Patterns]

The patterns proposed in this category focus on problems during runtime like runtime activities that span multiple services fail, the parent business task is incomplete etc

examples for this category are Agnostic SubController,Composition Autonomy,Atomic Service Transaction,Compensating ServiceTransaction

[http://www.soapatterns.org/masterlist_c.asp#ch20 Service Interaction Security Patterns]

The proposed patterns in this category are focused on security methods like encryption,decryption,authenticating the data,consumer and service

examples for this category are Data Confidentiality, Data Origin Authentication, Direct Authentication, Brokered Authentication

[http://www.soapatterns.org/masterlist_c.asp#ch21 Transformation Patterns]

The Patterns proposed in this category concrete on how data from one data model can be dynamically converted to comply to a different data model.

examples for this category are Data Model Transformation,Data Format Transformation, Protocol Bridging

[http://www.soapatterns.org/masterlist_c.asp#ch22 Common Compound Design Patterns]

A compound pattern is a coarse-grained pattern comprised of a set of finer-grained patterns.

examples for this category are Orchestration,Enterprise Service Bus,Service Broker,Canonical Schema Bus,Official Endpoint,Federated Endpoint Layer,Three-Layer Inventory

=Example Design Patterns =

The following section describes five design patterns which are utilized in SOA. The described patterns provide the problem and corresponding solution

==Canonical protocol==

[[Image:Canonicalpattern.jpg.png]]

Problem: Services that support different communication technologies compromise interoperability, limit the quantity of potential consumers, and introduce the need for undesirable protocol bridging measures.

Solution: The architecture establishes a single communications technology as the sole or primary medium by which services can interact.

From the above figure it is observed that the services are delivered by three different communication technologies A,B and C.These services are made to conform to one centralized communications technology, making them technologically compatible.with this these services can be delivered to consumers without much difficulty

==Dual protocol==

[[Image:dualprotocol.png]]

Problem: Canonical Protocol requires that all services conform to the use of the same communications technology; however, a single protocol may not be able to accommodate all service requirements, thereby introducing limitations.

Solution: The service inventory architecture is designed to support services based on primary and secondary protocols.

Regardless of protocol, all services must invoke each other via their official service contracts (A, B). Bypassing the contract may seem convenient when the underlying service logic of the primary service supports the same protocol as the secondary service (C), but it is an anti-pattern that will eventually inhibit the application of this pattern and further weaken the overall service inventory foundation.

==Protocol Bridging==

[[Image:protocolbridging.png]]

Problem: Services using different communication protocols or different versions of the same protocol cannot exchange data.

Solution: Bridging logic is introduced to enable communication between different communication protocols by dynamically converting one protocol to another at runtime.

From the above figure it can be noticed that the consumer programs interact with a middle-tier broker that provides protocol bridging features.The consumer programs may be using different protocols like Separate protocol adapters are used to translate the two incompatible protocols to the required SOAP version 1.2 over HTTP. The broker then transmits the messages to the service on behalf of the consumers.

==UI Mediator==

[[Image:uimediator.png]]

Problem: Because the behavior of individual services can vary depending on their design,runtime usage, and the workload required to carry out a given capability, the consistency with which a service-oriented solution can respond to requests originating from a user-interface can fluctuate, leading to a poor user experience.

Solution: Establish mediator logic solely responsible for ensuring timely interaction and feedback with user-interfaces and presentation logic.

In this method as can be observed from the figure the three services A,B and C work behind the scenes to complete the given task.The mediator service (D) regularly updates the user interface there by hiding the underlying logic to the consumer.

==Service Facade==

[[Image:service_facade.png]]

Problem: The coupling of the core service logic to contracts and implementation resources can inhibit its evolution and negatively impact service consumers.

Solution: A service facade component is used to abstract a part of the service architecture with negative coupling potential.

Facade logic is placed in between the contract and the core service logic. This allows the core service logic to remain decoupled from the contract.The objective of loose coupling is achieved by this process.the core logic abstraction is obtained by this way.

=Similarities and Differences Between Patterns for SOA and Traditional pattens proposed by GoF=

The Gang of Four(Gof) comprising of Eric Gamma, Richard Helm, Ralph Johnson, and John Vlissides have documented the design patterns that were followed by Software developers and architects in object oriented space. They have documented 23 design patterns which are collectively called as Traditional design patterns.

The design patterns in SOA are similiar in some aspects to the traditional patterns.They also differ from the traditional patterns. The similiarities and differences between them are provided in this section

==Differences==

The differences between the SOA design patterns and traditional design patterns have been come up based on the individual functionality that each pattern provide. Following are the differences,

1) The composite pattern organizes the objects in the manner to represent the part-whole hierarchies in a traditional two-tier hierarchy.

The [http://www.soapatterns.org/agnostic_subcontroller.asp agnostic sub-controller] implements the service composability but it differs from the composite pattern in such a way that cross-entity functionality is abstracted and made accessible through the sub –controller capability.

For instance, the traditional composite pattern has the object representing a part-whole hierarchy as in the below figure of graphic class which has draw(). If we require a cross-entity functionality as in the below figure, we require a colored rectangle, we require the functionality fill() of color class. Hence the sub-controller module is created which has the functionality of different parents, thus making it reusable.

figure to illustrate above difference

[[Image:Composite_example.png]]

2)
The traditional bridge pattern separates the abstraction from its implementation in order to vary independently. Whereas the canonical protocol avoids the protocol bridging in such a way that there is a single communication technology through which the services can interact.
In the below figure of bridge pattern, the relationship between the abstraction and implementor is bridge and it results the implementor to vary independently from the abstraction by having different ConcreteImplementor. The canonical protocol avoids the variation by having a single communication technology between different objects.

figure for above difference

[[Image:Traditional_bridge.png]]
Figure for Traditional bridge pattern

For canonical protocol refer to the explanation given in example design patterns

3) The traditional builder pattern decouples the construction of the object from its representation so that the same construction process can be used to develop different representations. The different representations (contracts) are addressed in SOA by the Concurrent Contracts with the application of Service-façade design pattern. With service-façade design pattern, an abstraction is created to support the interaction between different contracts. As a result, different contracts can be created for a single service.
In the below figure, the conversion of the text document is separated from the reader of RTF document, so that the text document can be represented in different forms like ASCIIText, TeXText and TextWidget. The different representation is achieved by decoupling of construction and abstraction. In the case of concurrent contracts pattern, the different contracts or services (invoices) are created for different consumer through service-façade by creating a new abstraction.

[[Image:Builder.png]]
Figure for Traditional Builder pattern

[[Image:Concurrent_pattern.png]]
Figure for Concurrent pattern

==Similarities==
1) The Service-façade design pattern is similar to the façade (traditional) pattern in the manner that it implements the façade logic which is creating an abstraction for intra-communication within objects to the service architecture. The advantage by adding the façade logic to the service architecture is that it preserves the underlying logic from run-time changes.

2) The UI Mediator design pattern implements the mediator logic of traditional mediator pattern. The mediator logic aims to provide the user responses in a way that user understands, independently of what the underlying services perform.

3) The Intermediate routing pattern in SOA is similar to Decorator pattern (traditional) in the functionality that it adds the required logic at run-time. The decorator adds the additional functionality to the object at run-time. The intermediate routing pattern is about placing the routing logic to address the run-time scenarios.

4)The Capability Composition pattern in SOA implements the Composite pattern (traditional). The Capability Composition is about composing one or more capabilities outside the service’s context to address the large, complex problem.

5) The Decoupled Contract pattern implements the traditional Bridge pattern in the manner that service contract is separated from the implementation. The Bridge pattern decouples the abstraction from implementation to facilitate the variation of both (abstraction and implementation).

6) The Legacy Wrapper pattern is related to traditional Adapter pattern. The Legacy Wrapper pattern protects the legacy logic by providing a standard service that takes of protecting the legacy details by encapsulating, extraction or elimination. The encapsulation, extraction or elimination is done in order to change the service as the consumer requires it. This is related to adapter in a way that it converts the interface of one class to another as the client expects.

=Summary=

=Glossary=

1.Serive : "A service is a discoverable resource that executes a repeatable task, and is described by an externalized service specification."

2.[http://www.ibm.com/developerworks/webservices/library/ws-soa-term1/ SOA Terminology]

3.SOA :[http://en.wikipedia.org/wiki/Service-oriented_architecture Service oriented Architecture]

4.API :[http://en.wikipedia.org/wiki/Application_programming_interface Application programming interface]

5.SOAP :[http://en.wikipedia.org/wiki/SOAP Simple Object Access Protocol]

6.HTTP :[http://en.wikipedia.org/wiki/HyperText_Transfer_Protocol Hypertext Transfer Protocol]

7.GoF :[http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Gang of Four]

8.[http://soaglossary.com/ SOA Glossory]

=References=

1.[http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Design patterns for object oriented software]

2.[http://en.wikipedia.org/wiki/Service-oriented_architecture#Introduction Service Oriented Architecture]

3.[http://www.exforsys.com/tutorials/soa/soa-definitions-and-certification.html SOA Tutorial]

4.[http://www.soapatterns.org/ soa design patterns]

5.[http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29 design pattern]

6.[http://www.oracle.com/technologies/soa/center.html oracle SOA centre]

7.[http://www.ibm.com/developerworks/webservices/library/ws-soa-term1/ IBMs SOA Contributions]

8.[http://www.oracle.com/technology/pub/articles/erl_soa_design_patterns_app_sequences.html SOA Design patterns application sequences by oracle]

CSC/ECE 517 Fall 2009/wiki2 16 rs

2009-10-10T02:55:16Z

Screenit: /* Design Patterns proposed */

CSC/ECE 517 Fall 2009/wiki2 16 rs

SOA provides another view of providing functionality based upon services offered in terms of protocols and a specific API. Research and report on what patterns have been proposed and are utilized within this domain. How do they differ from traditional design patterns proposed by Eric Gamma, Richard Helm, Ralph Johnson, and John Vlissides? How are they similar?

----
=Introduction=

This article focuses on the design patterns which are proposed and utilized in the [http://en.wikipedia.org/wiki/Service_oriented_architecture Service Oriented Architecture]. As the SOA provides its services through the protocols and API, this article throws light on the design patterns that specifically provide services through protocols like [http://www.soapatterns.org/canonical_protocol.asp Canonical protocol], [http://www.soapatterns.org/dual_protocols.asp Dual protocols] and [http://www.soapatterns.org/protocol_bridging.asp Protocol Bridging]. In a broader perspective, other design patterns have been explained tersely. In addition to explanation of the SOA design patterns, this compares the SOA design patterns with the traditional design patterns proposed by the ‘Gang of Four’ (Eric Gamma, Richard Helm, Ralph Johnson, and John Vlissides) and comes up with the differences and similarities between them.

=Service Oriented Architecture-An Overview=

==SOA-Definition==

A [http://en.wikipedia.org/wiki/Service_oriented_architecture Service Oriented Architecture] is an architecture that provides collection of services. These services need to inter-operate with each other to provide the functionality. This architecture requires a loose coupling with operating systems and other technologies that form the basis of the application. The loose coupling between services is required because each interaction has to be independent of the other. The communication between services could be either simple data being passed or it could be either an activity coordinated between distinct entities or services. Some means of interoperability is required to provide the services in larger terms. Instead of defining the API, the SOA implements the interfaces using the protocols and functionality. SOA separates functions into unique entities or services, which are accessed in a network by the users to combine and reuse them to develop the applications.

==Why SOA?==

Various businesses in the field of [http://en.wikipedia.org/wiki/Information_technology Information Technology] have to justify their projects with a return on their investments. This creates a pressure in Information Technology by making it a demanding field. Information Technology needs to have requirements in a way that it has to responsive and adapt to the changing requirements.

Information Technology companies must also be able to provide the services that are compatible with other services making it interoperable, thus creating dynamic services. Moreover, Information Technology has to face demands to bring new commercial services to a much wider array of customers. Customers may access services through web interfaces, or may be part of a supply chain that needs to decrease the time and cost of manufacturing.

Thus, Information Technology companies are always on the look out for solutions that will help them meet the above demands – without having to spend a lot of money. [http://en.wikipedia.org/wiki/Service_oriented_architecture Service Oriented Architecture] offers a solution to satisfy the above needs of the industry

==SOA-Benifits==
In architectural terms, a modern architectural design should be Service Oriented, loosely coupled, driven by events, able to support both integration and assembly, aligned with valuable life cycle support processes, and able to leverage existing infrastructure and applications.

When it comes to Service Oriented Architecture, it tends to offer a variety of different advantages over more traditional methods of distributing computing. These include
i) business services across several platforms
ii) location independence
iii) authentication as well as authorization support on different platforms
iv ) loosely coupled approach, dynamic search and connectivity to other services.

=Design Patterns in SOA=
A [http://en.wikipedia.org/wiki/Design_pattern design pattern] is a general reusable solution to a commonly occurring problem in software design. A design pattern is not a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be applied in different scenarios. Design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved.

Design patterns play a major role in SOA. The implementation and deployment of SOA designs provide different challenges during product development life cycle.Such challenges may make projects to be discontinued. Design patterns help in overcoming these problems by providing a solution to the problems posed. Each SOA design pattern provides a design solution in support of
successfully applying service orientation and establishing a quality service-oriented architecture

=Design Patterns proposed =

The proposed Design Patterns for SOA fall in to following categories. They are listed below and corresponding patterns in
each category are given. Detailed explanation of the design patterns given in the example can be found in the link provided for each category.

[http://www.soapatterns.org/masterlist_c.asp#ch6 Foundational Inventory Patterns]

These design patterns focus on providing solutions to the problems like maximizing re-composition and avoiding redundant logic.

Examples include Enterprise Inventory, Domain Inventory, Service Normalization, Logic Centralization, Service Layers Canonical Protocol, Canonical Schema

[http://www.soapatterns.org/masterlist_c.asp#ch7 Logical Inventory Layer Patterns]

These design patterns provide the solution to the problem of how can business logic be separated, reused, and governed independently?

examples for this category are Utility Abstraction,Entity Abstraction,Process Abstraction

[http://www.soapatterns.org/masterlist_c.asp#ch8 Inventory Centralization Patterns]

These patterns focus on providing solution for aspect of governing business logic etc

examples for this category are Process Centralization,Schema Centralization,Policy Centralization,Rules Centralization.

[http://www.soapatterns.org/masterlist_c.asp#ch9 Inventory Implementation Patterns]

These patterns help to solve implementation problems like limitations introduced by communication technology. Example like a single protocol may not accommodate all requirements etc

examples for this category are Dual Protocols,Canonical Resources,State Repository,Stateful Services,Service Grid,Inventory Endpoint,Cross-Domain Utility Layer

[http://www.soapatterns.org/masterlist_c.asp#ch10 Inventory Governance Patterns]

The patterns deal with the governance problems caused by service contract within the same service inventory

examples for this category are Canonical Expression,Metadata Centralization,Canonical Versioning

[http://www.soapatterns.org/masterlist_c.asp#ch11 Foundational Service Patterns]

The patterns proposed in this category focus on solving large business problems without having to build a stand alone solution.

examples for this category are Functional Decomposition,Service Encapsulation,Agnostic Context,Non-Agnostic Context,Agnostic Capability

[http://www.soapatterns.org/masterlist_c.asp#ch12 Service Implementation Patterns]

The patterns in this category focus on improving the realiability and availability of the service

examples for this category are Service Facade,Redundant Implementation,Service Data Replication,Partial State Deferral,Partial Validation,UI Mediator

[http://www.soapatterns.org/masterlist_c.asp#ch13 Service Security Patterns]

The patterns proposed in this category deal with the problem of data encapsulation and security aspects.

examples for this category are Exception Shielding,Message Screening,Trusted Subsystem ,Service Perimeter Guard

[http://www.soapatterns.org/masterlist_c.asp#ch14 Service Contract Design Patterns]

The patterns proposed in this category focus on providing solution for how to make the service contract suitable for all potential customers,make it aligned with other services etc

examples for this category are Decoupled Contract,Contract Centralization,Contract De normalization,Concurrent Contracts,Validation Abstraction

[http://www.soapatterns.org/masterlist_c.asp#ch15 Legacy Encapsulation Patterns]

The patterns proposed deals with the problems in legacy systems like processing of data contained in flat files, redundancy resulting in delivery to multiple channels etc

examples for this category are Legacy Wrapper, Multi-Channel Endpoint,File Gateway

[http://www.soapatterns.org/masterlist_c.asp#ch16 Service Governance Patterns]

These patterns provide solution for problems like updating the customers with changed service so that they are not affected, modifications in service etc

examples for this category are Compatible Change,Version Identification,Termination Notification,Service Refactoring,Service Decomposition,Proxy Capability,Decomposed Capability,Distributed Capability

[http://www.soapatterns.org/masterlist_c.asp#ch17 Capability Composition Patterns]

The pattern proposed focuses on the problem of How can a service capability solve a problem that requires logic outside of the service boundary and How can the same capability be used to help solve multiple problems?

examples for this category are Capability Composition,Capability Recomposition

[http://www.soapatterns.org/masterlist_c.asp#ch18 Service Messaging Patterns]

The patterns proposed in this category focus on setting up of message framework for transfer of data.

examples in this category are Service Messaging,Messaging Metadata,Service Agent,Intermediate Routing,State Messaging,Service Callback,Service Instance Routing,Asynchronous Queuing,Reliable Messaging,Event-Driven Messaging.

[http://www.soapatterns.org/masterlist_c.asp#ch19 Composition Implementation Patterns]

The patterns proposed in this category focus on problems during runtime like runtime activities that span multiple services fail, the parent business task is incomplete etc

examples for this category are Agnostic SubController,Composition Autonomy,Atomic Service Transaction,Compensating ServiceTransaction

[http://www.soapatterns.org/masterlist_c.asp#ch20 Service Interaction Security Patterns]

The proposed patterns in this category are focused on security methods like encryption,decryption,authenticating the data,consumer and service

examples for this category are Data Confidentiality, Data Origin Authentication, Direct Authentication, Brokered Authentication

[http://www.soapatterns.org/masterlist_c.asp#ch21 Transformation Patterns]

The Patterns proposed in this category concrete on how data from one data model can be dynamically converted to comply to a different data model.

examples for this category are Data Model Transformation,Data Format Transformation, Protocol Bridging

[http://www.soapatterns.org/masterlist_c.asp#ch22 Common Compound Design Patterns]

A compound pattern is a coarse-grained pattern comprised of a set of finer-grained patterns.

examples for this category are Orchestration,Enterprise Service Bus,Service Broker,Canonical Schema Bus,Official Endpoint,Federated Endpoint Layer,Three-Layer Inventory

=Example Design Patterns =

The following section describes five design patterns which are utilized in SOA.The described patterns provide the problem and corresponding solution

==Canonical protocol==

[[Image:Canonicalpattern.jpg.png]]

Problem: Services that support different communication technologies compromise interoperability, limit the quantity of potential consumers, and introduce the need for undesirable protocol bridging measures.

Solution: The architecture establishes a single communications technology as the sole or primary medium by which services can interact.

From the above figure it is observed that the services are delivered by three different communication technologies A,B and C.These services are made to conform to one centralized communications technology, making them technologically compatible.with this these services can be delivered to consumers without much difficulty

==Dual protocol==

[[Image:dualprotocol.png]]

Problem: Canonical Protocol requires that all services conform to the use of the same communications technology; however, a single protocol may not be able to accommodate all service requirements, thereby introducing limitations.

Solution: The service inventory architecture is designed to support services based on primary and secondary protocols.

Regardless of protocol, all services must invoke each other via their official service contracts (A, B). Bypassing the contract may seem convenient when the underlying service logic of the primary service supports the same protocol as the secondary service (C), but it is an anti-pattern that will eventually inhibit the application of this pattern and further weaken the overall service inventory foundation.

==Protocol Bridging==

[[Image:protocolbridging.png]]

Problem: Services using different communication protocols or different versions of the same protocol cannot exchange data.

Solution: Bridging logic is introduced to enable communication between different communication protocols by dynamically converting one protocol to another at runtime.

From the above figure it can be noticed that the consumer programs interact with a middle-tier broker that provides protocol bridging features. Separate protocol adapters are used to translate the two incompatible protocols to the required SOAP version 1.2 over HTTP. The broker then transmits the messages to the service on behalf of the consumers.

==UI Mediator==

[[Image:uimediator.png]]

Problem: Because the behavior of individual services can vary depending on their design,runtime usage, and the workload required to carry out a given capability, the consistency with which a service-oriented solution can respond to requests originating from a user-interface can fluctuate, leading to a poor user experience.

Solution: Establish mediator logic solely responsible for ensuring timely interaction and feedback with user-interfaces and presentation logic.

In this method as can be observed from the figure the three services A,B and C work behind the scenes to complete the given task.The mediator service (D) regularly updates the user interface there by hiding the underlying logic to the consumer.

==Service Facade==

[[Image:service_facade.png]]

Problem: The coupling of the core service logic to contracts and implementation resources can inhibit its evolution and negatively impact service consumers.

Solution: A service facade component is used to abstract a part of the service architecture with negative coupling potential.

Facade logic is placed in between the contract and the core service logic. This allows the core service logic to remain decoupled from the contract.The objective of loose coupling is achieved by this process.the core logic abstraction is obtained by this way.

=Similarities and Differences Between Patterns for SOA and Traditional pattens proposed by GoF=

The Gang of Four(Gof) comprising of Eric Gamma, Richard Helm, Ralph Johnson, and John Vlissides have documented the design patterns that were followed by Software developers and architects in object oriented space. They have documented 23 design patterns which are collectively called as Traditional design patterns.

The design patterns in SOA are similiar in some aspects to the traditional patterns.They also differ from the traditional patterns. The similiarities and differences between them are provided in this section

==Differences==

The differences between the SOA design patterns and traditional design patterns have been come up based on the individual functionality that each pattern provide. Following are the differences,

1) The composite pattern organizes the objects in the manner to represent the part-whole hierarchies in a traditional two-tier hierarchy.

The [http://www.soapatterns.org/agnostic_subcontroller.asp agnostic sub-controller] implements the service composability but it differs from the composite pattern in such a way that cross-entity functionality is abstracted and made accessible through the sub –controller capability.

For instance, the traditional composite pattern has the object representing a part-whole hierarchy as in the below figure of graphic class which has draw(). If we require a cross-entity functionality as in the below figure, we require a colored rectangle, we require the functionality fill() of color class. Hence the sub-controller module is created which has the functionality of different parents, thus making it reusable.

figure to illustrate above difference

[[Image:Composite_example.png]]

2)
The traditional bridge pattern separates the abstraction from its implementation in order to vary independently. Whereas the canonical protocol avoids the protocol bridging in such a way that there is a single communication technology through which the services can interact.
In the below figure of bridge pattern, the relationship between the abstraction and implementor is bridge and it results the implementor to vary independently from the abstraction by having different ConcreteImplementor. The canonical protocol avoids the variation by having a single communication technology between different objects.

figure for above difference

[[Image:Traditional_bridge.png]]
Figure for Traditional bridge pattern

For canonical protocol refer to the explanation given in example design patterns

3) The traditional builder pattern decouples the construction of the object from its representation so that the same construction process can be used to develop different representations. The different representations (contracts) are addressed in SOA by the Concurrent Contracts with the application of Service-façade design pattern. With service-façade design pattern, an abstraction is created to support the interaction between different contracts. As a result, different contracts can be created for a single service.
In the below figure, the conversion of the text document is separated from the reader of RTF document, so that the text document can be represented in different forms like ASCIIText, TeXText and TextWidget. The different representation is achieved by decoupling of construction and abstraction. In the case of concurrent contracts pattern, the different contracts or services (invoices) are created for different consumer through service-façade by creating a new abstraction.

[[Image:Builder.png]]
Figure for Traditional Builder pattern

[[Image:Concurrent_pattern.png]]
Figure for Concurrent pattern

==Similarities==
1) The Service-façade design pattern is similar to the façade (traditional) pattern in the manner that it implements the façade logic which is creating an abstraction for intra-communication within objects to the service architecture. The advantage by adding the façade logic to the service architecture is that it preserves the underlying logic from run-time changes.

2) The UI Mediator design pattern implements the mediator logic of traditional mediator pattern. The mediator logic aims to provide the user responses in a way that user understands, independently of what the underlying services perform.

3) The Intermediate routing pattern in SOA is similar to Decorator pattern (traditional) in the functionality that it adds the required logic at run-time. The decorator adds the additional functionality to the object at run-time. The intermediate routing pattern is about placing the routing logic to address the run-time scenarios.

4)The Capability Composition pattern in SOA implements the Composite pattern (traditional). The Capability Composition is about composing one or more capabilities outside the service’s context to address the large, complex problem.

5) The Decoupled Contract pattern implements the traditional Bridge pattern in the manner that service contract is separated from the implementation. The Bridge pattern decouples the abstraction from implementation to facilitate the variation of both (abstraction and implementation).

6) The Legacy Wrapper pattern is related to traditional Adapter pattern. The Legacy Wrapper pattern protects the legacy logic by providing a standard service that takes of protecting the legacy details by encapsulating, extraction or elimination. The encapsulation, extraction or elimination is done in order to change the service as the consumer requires it. This is related to adapter in a way that it converts the interface of one class to another as the client expects.

=Summary=

=Glossary=

1.Serive : "A service is a discoverable resource that executes a repeatable task, and is described by an externalized service specification."

2.[http://www.ibm.com/developerworks/webservices/library/ws-soa-term1/ SOA Terminology]

3.SOA :[http://en.wikipedia.org/wiki/Service-oriented_architecture Service oriented Architecture]

4.API :[http://en.wikipedia.org/wiki/Application_programming_interface Application programming interface]

5.SOAP :[http://en.wikipedia.org/wiki/SOAP Simple Object Access Protocol]

6.HTTP :[http://en.wikipedia.org/wiki/HyperText_Transfer_Protocol Hypertext Transfer Protocol]

7.GoF :[http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Gang of Four]

8.[http://soaglossary.com/ SOA Glossory]

=References=

1.[http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Design patterns for object oriented software]

2.[http://en.wikipedia.org/wiki/Service-oriented_architecture#Introduction Service Oriented Architecture]

3.[http://www.exforsys.com/tutorials/soa/soa-definitions-and-certification.html SOA Tutorial]

4.[http://www.soapatterns.org/ soa design patterns]

5.[http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29 design pattern]

6.[http://www.oracle.com/technologies/soa/center.html oracle SOA centre]

7.[http://www.ibm.com/developerworks/webservices/library/ws-soa-term1/ IBMs SOA Contributions]

8.[http://www.oracle.com/technology/pub/articles/erl_soa_design_patterns_app_sequences.html SOA Design patterns application sequences by oracle]

CSC/ECE 517 Fall 2009/wiki2 16 rs

2009-10-10T02:49:37Z

Screenit: /* Design Patterns proposed */

CSC/ECE 517 Fall 2009/wiki2 16 rs

SOA provides another view of providing functionality based upon services offered in terms of protocols and a specific API. Research and report on what patterns have been proposed and are utilized within this domain. How do they differ from traditional design patterns proposed by Eric Gamma, Richard Helm, Ralph Johnson, and John Vlissides? How are they similar?

----
=Introduction=

This article focuses on the design patterns which are proposed and utilized in the [http://en.wikipedia.org/wiki/Service_oriented_architecture Service Oriented Architecture]. As the SOA provides its services through the protocols and API, this article throws light on the design patterns that specifically provide services through protocols like [http://www.soapatterns.org/canonical_protocol.asp Canonical protocol], [http://www.soapatterns.org/dual_protocols.asp Dual protocols] and [http://www.soapatterns.org/protocol_bridging.asp Protocol Bridging]. In a broader perspective, other design patterns have been explained tersely. In addition to explanation of the SOA design patterns, this compares the SOA design patterns with the traditional design patterns proposed by the ‘Gang of Four’ (Eric Gamma, Richard Helm, Ralph Johnson, and John Vlissides) and comes up with the differences and similarities between them.

=Service Oriented Architecture-An Overview=

==SOA-Definition==

A [http://en.wikipedia.org/wiki/Service_oriented_architecture Service Oriented Architecture] is an architecture that provides collection of services. These services need to inter-operate with each other to provide the functionality. This architecture requires a loose coupling with operating systems and other technologies that form the basis of the application. The loose coupling between services is required because each interaction has to be independent of the other. The communication between services could be either simple data being passed or it could be either an activity coordinated between distinct entities or services. Some means of interoperability is required to provide the services in larger terms. Instead of defining the API, the SOA implements the interfaces using the protocols and functionality. SOA separates functions into unique entities or services, which are accessed in a network by the users to combine and reuse them to develop the applications.

==Why SOA?==

Various businesses in the field of [http://en.wikipedia.org/wiki/Information_technology Information Technology] have to justify their projects with a return on their investments. This creates a pressure in Information Technology by making it a demanding field. Information Technology needs to have requirements in a way that it has to responsive and adapt to the changing requirements.

Information Technology companies must also be able to provide the services that are compatible with other services making it interoperable, thus creating dynamic services. Moreover, Information Technology has to face demands to bring new commercial services to a much wider array of customers. Customers may access services through web interfaces, or may be part of a supply chain that needs to decrease the time and cost of manufacturing.

Thus, Information Technology companies are always on the look out for solutions that will help them meet the above demands – without having to spend a lot of money. [http://en.wikipedia.org/wiki/Service_oriented_architecture Service Oriented Architecture] offers a solution to satisfy the above needs of the industry

==SOA-Benifits==
In architectural terms, a modern architectural design should be Service Oriented, loosely coupled, driven by events, able to support both integration and assembly, aligned with valuable life cycle support processes, and able to leverage existing infrastructure and applications.

When it comes to Service Oriented Architecture, it tends to offer a variety of different advantages over more traditional methods of distributing computing. These include
i) business services across several platforms
ii) location independence
iii) authentication as well as authorization support on different platforms
iv ) loosely coupled approach, dynamic search and connectivity to other services.

=Design Patterns in SOA=
A [http://en.wikipedia.org/wiki/Design_pattern design pattern] is a general reusable solution to a commonly occurring problem in software design. A design pattern is not a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be applied in different scenarios. Design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved.

Design patterns play a major role in SOA. The implementation and deployment of SOA designs provide different challenges during product development life cycle.Such challenges may make projects to be discontinued. Design patterns help in overcoming these problems by providing a solution to the problems posed. Each SOA design pattern provides a design solution in support of
successfully applying service orientation and establishing a quality service-oriented architecture

=Design Patterns proposed =

The proposed Design Patterns for SOA fall in to following categories.They are listed below and corresponding patterns in
each category are given.

[http://www.soapatterns.org/masterlist_c.asp#ch6 Foundational Inventory Patterns]

These design patterns focus on providing solutions to the problems like maximizing re-composition and avoiding redundant logic.

Examples include Enterprise Inventory, Domain Inventory, Service Normalization, Logic Centralization, Service Layers Canonical Protocol, Canonical Schema

[http://www.soapatterns.org/masterlist_c.asp#ch7 Logical Inventory Layer Patterns]

These design patterns provide the solution to the problem of how can business logic be separated, reused, and governed independently?

examples for this category are Utility Abstraction,Entity Abstraction,Process Abstraction

[http://www.soapatterns.org/masterlist_c.asp#ch8 Inventory Centralization Patterns]

These patterns focus on providing solution for aspect of governing business logic etc

examples for this category are Process Centralization,Schema Centralization,Policy Centralization,Rules Centralization.

[http://www.soapatterns.org/masterlist_c.asp#ch9 Inventory Implementation Patterns]

These patterns help to solve implementation problems like limitations introduced by communication technology. Example like a single protocol may not accommodate all requirements etc

examples for this category are Dual Protocols,Canonical Resources,State Repository,Stateful Services,Service Grid,Inventory Endpoint,Cross-Domain Utility Layer

[http://www.soapatterns.org/masterlist_c.asp#ch10 Inventory Governance Patterns]

The patterns deal with the governance problems caused by service contract within the same service inventory

examples for this category are Canonical Expression,Metadata Centralization,Canonical Versioning

[http://www.soapatterns.org/masterlist_c.asp#ch11 Foundational Service Patterns]

The patterns proposed in this category focus on solving large business problems without having to build a stand alone solution.

examples for this category are Functional Decomposition,Service Encapsulation,Agnostic Context,Non-Agnostic Context,Agnostic Capability

[http://www.soapatterns.org/masterlist_c.asp#ch12 Service Implementation Patterns]

The patterns in this category focus on improving the realiability and availability of the service

examples for this category are Service Facade,Redundant Implementation,Service Data Replication,Partial State Deferral,Partial Validation,UI Mediator

[http://www.soapatterns.org/masterlist_c.asp#ch13 Service Security Patterns]

The patterns proposed in this category deal with the problem of data encapsulation and security aspects.

examples for this category are Exception Shielding,Message Screening,Trusted Subsystem ,Service Perimeter Guard

[http://www.soapatterns.org/masterlist_c.asp#ch14 Service Contract Design Patterns]

The patterns proposed in this category focus on providing solution for how to make the service contract suitable for all potential customers,make it aligned with other services etc

examples for this category are Decoupled Contract,Contract Centralization,Contract De normalization,Concurrent Contracts,Validation Abstraction

[http://www.soapatterns.org/masterlist_c.asp#ch15 Legacy Encapsulation Patterns]

The patterns proposed deals with the problems in legacy systems like processing of data contained in flat files, redundancy resulting in delivery to multiple channels etc

examples for this category are Legacy Wrapper, Multi-Channel Endpoint,File Gateway

[http://www.soapatterns.org/masterlist_c.asp#ch16 Service Governance Patterns]

These patterns provide solution for problems like updating the customers with changed service so that they are not affected, modifications in service etc

examples for this category are Compatible Change,Version Identification,Termination Notification,Service Refactoring,Service Decomposition,Proxy Capability,Decomposed Capability,Distributed Capability

[http://www.soapatterns.org/masterlist_c.asp#ch17 Capability Composition Patterns]

The pattern proposed focuses on the problem of How can a service capability solve a problem that requires logic outside of the service boundary and How can the same capability be used to help solve multiple problems?

examples for this category are Capability Composition,Capability Recomposition

[http://www.soapatterns.org/masterlist_c.asp#ch18 Service Messaging Patterns]

The patterns proposed in this category focus on setting up of message framework for transfer of data.

examples in this category are Service Messaging,Messaging Metadata,Service Agent,Intermediate Routing,State Messaging,Service Callback,Service Instance Routing,Asynchronous Queuing,Reliable Messaging,Event-Driven Messaging.

[http://www.soapatterns.org/masterlist_c.asp#ch19 Composition Implementation Patterns]

The patterns proposed in this category focus on problems during runtime like runtime activities that span multiple services fail, the parent business task is incomplete etc

examples for this category are Agnostic SubController,Composition Autonomy,Atomic Service Transaction,Compensating ServiceTransaction

[http://www.soapatterns.org/masterlist_c.asp#ch20 Service Interaction Security Patterns]

The proposed patterns in this category are focused on security methods like encryption,decryption,authenticating the data,consumer and service

examples for this category are Data Confidentiality, Data Origin Authentication, Direct Authentication, Brokered Authentication

[http://www.soapatterns.org/masterlist_c.asp#ch21 Transformation Patterns]

The Patterns proposed in this category concrete on how data from one data model can be dynamically converted to comply to a different data model.

examples for this category are Data Model Transformation,Data Format Transformation, Protocol Bridging

[http://www.soapatterns.org/masterlist_c.asp#ch22 Common Compound Design Patterns]

A compound pattern is a coarse-grained pattern comprised of a set of finer-grained patterns.

examples for this category are Orchestration,Enterprise Service Bus,Service Broker,Canonical Schema Bus,Official Endpoint,Federated Endpoint Layer,Three-Layer Inventory

=Example Design Patterns =

The following section describes five design patterns which are utilized in SOA.The described patterns provide the problem and corresponding solution

==Canonical protocol==

[[Image:Canonicalpattern.jpg.png]]

Problem: Services that support different communication technologies compromise interoperability, limit the quantity of potential consumers, and introduce the need for undesirable protocol bridging measures.

Solution: The architecture establishes a single communications technology as the sole or primary medium by which services can interact.

From the above figure it is observed that the services are delivered by three different communication technologies A,B and C.These services are made to conform to one centralized communications technology, making them technologically compatible.with this these services can be delivered to consumers without much difficulty

==Dual protocol==

[[Image:dualprotocol.png]]

Problem: Canonical Protocol requires that all services conform to the use of the same communications technology; however, a single protocol may not be able to accommodate all service requirements, thereby introducing limitations.

Solution: The service inventory architecture is designed to support services based on primary and secondary protocols.

Regardless of protocol, all services must invoke each other via their official service contracts (A, B). Bypassing the contract may seem convenient when the underlying service logic of the primary service supports the same protocol as the secondary service (C), but it is an anti-pattern that will eventually inhibit the application of this pattern and further weaken the overall service inventory foundation.

==Protocol Bridging==

[[Image:protocolbridging.png]]

Problem: Services using different communication protocols or different versions of the same protocol cannot exchange data.

Solution: Bridging logic is introduced to enable communication between different communication protocols by dynamically converting one protocol to another at runtime.

From the above figure it can be noticed that the consumer programs interact with a middle-tier broker that provides protocol bridging features. Separate protocol adapters are used to translate the two incompatible protocols to the required SOAP version 1.2 over HTTP. The broker then transmits the messages to the service on behalf of the consumers.

==UI Mediator==

[[Image:uimediator.png]]

Problem: Because the behavior of individual services can vary depending on their design,runtime usage, and the workload required to carry out a given capability, the consistency with which a service-oriented solution can respond to requests originating from a user-interface can fluctuate, leading to a poor user experience.

Solution: Establish mediator logic solely responsible for ensuring timely interaction and feedback with user-interfaces and presentation logic.

The mediator service (D) regularly updates the user interface while services A, B, and C work behind-the-scenes to complete the task

==Service Facade==

[[Image:service_facade.png]]

Problem: The coupling of the core service logic to contracts and implementation resources can inhibit its evolution and negatively impact service consumers.

Solution: A service facade component is used to abstract a part of the service architecture with negative coupling potential.

Facade logic is placed in between the contract and the core service logic. This allows the core service logic to remain decoupled from the contract.The objective of loose coupling is achieved by this process.the core logic abstraction is obtained by this way.

=Similarities and Differences Between Patterns for SOA and Traditional pattens proposed by GoF=

The Gang of Four(Gof) comprising of Eric Gamma, Richard Helm, Ralph Johnson, and John Vlissides have documented the design patterns that were followed by Software developers and architects in object oriented space. They have documented 23 design patterns which are collectively called as Traditional design patterns.

The design patterns in SOA are similiar in some aspects to the traditional patterns.They also differ from the traditional patterns. The similiarities and differences between them are provided in this section

==Differences==

The differences between the SOA design patterns and traditional design patterns have been come up based on the individual functionality that each pattern provide. Following are the differences,

1) The composite pattern organizes the objects in the manner to represent the part-whole hierarchies in a traditional two-tier hierarchy.

The [http://www.soapatterns.org/agnostic_subcontroller.asp agnostic sub-controller] implements the service composability but it differs from the composite pattern in such a way that cross-entity functionality is abstracted and made accessible through the sub –controller capability.

For instance, the traditional composite pattern has the object representing a part-whole hierarchy as in the below figure of graphic class which has draw(). If we require a cross-entity functionality as in the below figure, we require a colored rectangle, we require the functionality fill() of color class. Hence the sub-controller module is created which has the functionality of different parents, thus making it reusable.

figure to illustrate above difference

[[Image:Composite_example.png]]

2)
The traditional bridge pattern separates the abstraction from its implementation in order to vary independently. Whereas the canonical protocol avoids the protocol bridging in such a way that there is a single communication technology through which the services can interact.
In the below figure of bridge pattern, the relationship between the abstraction and implementor is bridge and it results the implementor to vary independently from the abstraction by having different ConcreteImplementor. The canonical protocol avoids the variation by having a single communication technology between different objects.

figure for above difference

[[Image:Traditional_bridge.png]]
Figure for Traditional bridge pattern

For canonical protocol refer to the explanation given in example design patterns

3) The traditional builder pattern decouples the construction of the object from its representation so that the same construction process can be used to develop different representations. The different representations (contracts) are addressed in SOA by the Concurrent Contracts with the application of Service-façade design pattern. With service-façade design pattern, an abstraction is created to support the interaction between different contracts. As a result, different contracts can be created for a single service.
In the below figure, the conversion of the text document is separated from the reader of RTF document, so that the text document can be represented in different forms like ASCIIText, TeXText and TextWidget. The different representation is achieved by decoupling of construction and abstraction. In the case of concurrent contracts pattern, the different contracts or services (invoices) are created for different consumer through service-façade by creating a new abstraction.

[[Image:Builder.png]]
Figure for Traditional Builder pattern

[[Image:Concurrent_pattern.png]]
Figure for Concurrent pattern

==Similarities==
1) The Service-façade design pattern is similar to the façade (traditional) pattern in the manner that it implements the façade logic which is creating an abstraction for intra-communication within objects to the service architecture. The advantage by adding the façade logic to the service architecture is that it preserves the underlying logic from run-time changes.

2) The UI Mediator design pattern implements the mediator logic of traditional mediator pattern. The mediator logic aims to provide the user responses in a way that user understands, independently of what the underlying services perform.

3) The Intermediate routing pattern in SOA is similar to Decorator pattern (traditional) in the functionality that it adds the required logic at run-time. The decorator adds the additional functionality to the object at run-time. The intermediate routing pattern is about placing the routing logic to address the run-time scenarios.

4)The Capability Composition pattern in SOA implements the Composite pattern (traditional). The Capability Composition is about composing one or more capabilities outside the service’s context to address the large, complex problem.

5) The Decoupled Contract pattern implements the traditional Bridge pattern in the manner that service contract is separated from the implementation. The Bridge pattern decouples the abstraction from implementation to facilitate the variation of both (abstraction and implementation).

6) The Legacy Wrapper pattern is related to traditional Adapter pattern. The Legacy Wrapper pattern protects the legacy logic by providing a standard service that takes of protecting the legacy details by encapsulating, extraction or elimination. The encapsulation, extraction or elimination is done in order to change the service as the consumer requires it. This is related to adapter in a way that it converts the interface of one class to another as the client expects.

=Summary=

=Glossary=

1.Serive : "A service is a discoverable resource that executes a repeatable task, and is described by an externalized service specification."

2.[http://www.ibm.com/developerworks/webservices/library/ws-soa-term1/ SOA Terminology]

3.SOA :[http://en.wikipedia.org/wiki/Service-oriented_architecture Service oriented Architecture]

4.API :[http://en.wikipedia.org/wiki/Application_programming_interface Application programming interface]

5.SOAP :[http://en.wikipedia.org/wiki/SOAP Simple Object Access Protocol]

6.HTTP :[http://en.wikipedia.org/wiki/HyperText_Transfer_Protocol Hypertext Transfer Protocol]

7.GoF :[http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Gang of Four]

8.[http://soaglossary.com/ SOA Glossory]

=References=

1.[http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Design patterns for object oriented software]

2.[http://en.wikipedia.org/wiki/Service-oriented_architecture#Introduction Service Oriented Architecture]

3.[http://www.exforsys.com/tutorials/soa/soa-definitions-and-certification.html SOA Tutorial]

4.[http://www.soapatterns.org/ soa design patterns]

5.[http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29 design pattern]

6.[http://www.oracle.com/technologies/soa/center.html oracle SOA centre]

7.[http://www.ibm.com/developerworks/webservices/library/ws-soa-term1/ IBMs SOA Contributions]

8.[http://www.oracle.com/technology/pub/articles/erl_soa_design_patterns_app_sequences.html SOA Design patterns application sequences by oracle]

CSC/ECE 517 Fall 2009/wiki2 16 rs

2009-10-10T02:48:02Z

Screenit: /* Design Patterns in SOA */

CSC/ECE 517 Fall 2009/wiki2 16 rs

SOA provides another view of providing functionality based upon services offered in terms of protocols and a specific API. Research and report on what patterns have been proposed and are utilized within this domain. How do they differ from traditional design patterns proposed by Eric Gamma, Richard Helm, Ralph Johnson, and John Vlissides? How are they similar?

----
=Introduction=

This article focuses on the design patterns which are proposed and utilized in the [http://en.wikipedia.org/wiki/Service_oriented_architecture Service Oriented Architecture]. As the SOA provides its services through the protocols and API, this article throws light on the design patterns that specifically provide services through protocols like [http://www.soapatterns.org/canonical_protocol.asp Canonical protocol], [http://www.soapatterns.org/dual_protocols.asp Dual protocols] and [http://www.soapatterns.org/protocol_bridging.asp Protocol Bridging]. In a broader perspective, other design patterns have been explained tersely. In addition to explanation of the SOA design patterns, this compares the SOA design patterns with the traditional design patterns proposed by the ‘Gang of Four’ (Eric Gamma, Richard Helm, Ralph Johnson, and John Vlissides) and comes up with the differences and similarities between them.

=Service Oriented Architecture-An Overview=

==SOA-Definition==

A [http://en.wikipedia.org/wiki/Service_oriented_architecture Service Oriented Architecture] is an architecture that provides collection of services. These services need to inter-operate with each other to provide the functionality. This architecture requires a loose coupling with operating systems and other technologies that form the basis of the application. The loose coupling between services is required because each interaction has to be independent of the other. The communication between services could be either simple data being passed or it could be either an activity coordinated between distinct entities or services. Some means of interoperability is required to provide the services in larger terms. Instead of defining the API, the SOA implements the interfaces using the protocols and functionality. SOA separates functions into unique entities or services, which are accessed in a network by the users to combine and reuse them to develop the applications.

==Why SOA?==

Various businesses in the field of [http://en.wikipedia.org/wiki/Information_technology Information Technology] have to justify their projects with a return on their investments. This creates a pressure in Information Technology by making it a demanding field. Information Technology needs to have requirements in a way that it has to responsive and adapt to the changing requirements.

Information Technology companies must also be able to provide the services that are compatible with other services making it interoperable, thus creating dynamic services. Moreover, Information Technology has to face demands to bring new commercial services to a much wider array of customers. Customers may access services through web interfaces, or may be part of a supply chain that needs to decrease the time and cost of manufacturing.

Thus, Information Technology companies are always on the look out for solutions that will help them meet the above demands – without having to spend a lot of money. [http://en.wikipedia.org/wiki/Service_oriented_architecture Service Oriented Architecture] offers a solution to satisfy the above needs of the industry

==SOA-Benifits==
In architectural terms, a modern architectural design should be Service Oriented, loosely coupled, driven by events, able to support both integration and assembly, aligned with valuable life cycle support processes, and able to leverage existing infrastructure and applications.

When it comes to Service Oriented Architecture, it tends to offer a variety of different advantages over more traditional methods of distributing computing. These include
i) business services across several platforms
ii) location independence
iii) authentication as well as authorization support on different platforms
iv ) loosely coupled approach, dynamic search and connectivity to other services.

=Design Patterns in SOA=
A [http://en.wikipedia.org/wiki/Design_pattern design pattern] is a general reusable solution to a commonly occurring problem in software design. A design pattern is not a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be applied in different scenarios. Design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved.

Design patterns play a major role in SOA. The implementation and deployment of SOA designs provide different challenges during product development life cycle.Such challenges may make projects to be discontinued. Design patterns help in overcoming these problems by providing a solution to the problems posed. Each SOA design pattern provides a design solution in support of
successfully applying service orientation and establishing a quality service-oriented architecture

=Design Patterns proposed =

The proposed Design Patterns for SOA fall in to following categories.They are listed below and corresponding patterns in
each category are given.

[http://www.soapatterns.org/masterlist_c.asp#ch6 Foundational Inventory Patterns]

These design patterns focus on providing solutions to the problems like maximizing re-composition and avoiding redundant logic .

examples for this category are Enterprise Inventory,Domain Inventory,Service Normalization,Logic Centralization, Service Layers Canonical Protocol,Canonical Schema

[http://www.soapatterns.org/masterlist_c.asp#ch7 Logical Inventory Layer Patterns]

These design patterns provide the solution to the problem of how can business logic be separated, reused, and governed independently?

examples for this category are Utility Abstraction,Entity Abstraction,Process Abstraction

[http://www.soapatterns.org/masterlist_c.asp#ch8 Inventory Centralization Patterns]

These patterns focus on providing solution for aspect of governing business logic etc

examples for this category are Process Centralization,Schema Centralization,Policy Centralization,Rules Centralization.

[http://www.soapatterns.org/masterlist_c.asp#ch9 Inventory Implementation Patterns]

These patterns help to solve implementation problems like limitations introduced by communication technology. Example like a single protocol may not accommodate all requirements etc

examples for this category are Dual Protocols,Canonical Resources,State Repository,Stateful Services,Service Grid,Inventory Endpoint,Cross-Domain Utility Layer

[http://www.soapatterns.org/masterlist_c.asp#ch10 Inventory Governance Patterns]

The patterns deal with the governance problems caused by service contract within the same service inventory

examples for this category are Canonical Expression,Metadata Centralization,Canonical Versioning

[http://www.soapatterns.org/masterlist_c.asp#ch11 Foundational Service Patterns]

The patterns proposed in this category focus on solving large business problems without having to build a stand alone solution.

examples for this category are Functional Decomposition,Service Encapsulation,Agnostic Context,Non-Agnostic Context,Agnostic Capability

[http://www.soapatterns.org/masterlist_c.asp#ch12 Service Implementation Patterns]

The patterns in this category focus on improving the realiability and availability of the service

examples for this category are Service Facade,Redundant Implementation,Service Data Replication,Partial State Deferral,Partial Validation,UI Mediator

[http://www.soapatterns.org/masterlist_c.asp#ch13 Service Security Patterns]

The patterns proposed in this category deal with the problem of data encapsulation and security aspects.

examples for this category are Exception Shielding,Message Screening,Trusted Subsystem ,Service Perimeter Guard

[http://www.soapatterns.org/masterlist_c.asp#ch14 Service Contract Design Patterns]

The patterns proposed in this category focus on providing solution for how to make the service contract suitable for all potential customers,make it aligned with other services etc

examples for this category are Decoupled Contract,Contract Centralization,Contract De normalization,Concurrent Contracts,Validation Abstraction

[http://www.soapatterns.org/masterlist_c.asp#ch15 Legacy Encapsulation Patterns]

The patterns proposed deals with the problems in legacy systems like processing of data contained in flat files, redundancy resulting in delivery to multiple channels etc

examples for this category are Legacy Wrapper, Multi-Channel Endpoint,File Gateway

[http://www.soapatterns.org/masterlist_c.asp#ch16 Service Governance Patterns]

These patterns provide solution for problems like updating the customers with changed service so that they are not affected, modifications in service etc

examples for this category are Compatible Change,Version Identification,Termination Notification,Service Refactoring,Service Decomposition,Proxy Capability,Decomposed Capability,Distributed Capability

[http://www.soapatterns.org/masterlist_c.asp#ch17 Capability Composition Patterns]

The pattern proposed focuses on the problem of How can a service capability solve a problem that requires logic outside of the service boundary and How can the same capability be used to help solve multiple problems?

examples for this category are Capability Composition,Capability Recomposition

[http://www.soapatterns.org/masterlist_c.asp#ch18 Service Messaging Patterns]

The patterns proposed in this category focus on setting up of message framework for transfer of data.

examples in this category are Service Messaging,Messaging Metadata,Service Agent,Intermediate Routing,State Messaging,Service Callback,Service Instance Routing,Asynchronous Queuing,Reliable Messaging,Event-Driven Messaging.

[http://www.soapatterns.org/masterlist_c.asp#ch19 Composition Implementation Patterns]

The patterns proposed in this category focus on problems during runtime like runtime activities that span multiple services fail, the parent business task is incomplete etc

examples for this category are Agnostic SubController,Composition Autonomy,Atomic Service Transaction,Compensating ServiceTransaction

[http://www.soapatterns.org/masterlist_c.asp#ch20 Service Interaction Security Patterns]

The proposed patterns in this category are focused on security methods like encryption,decryption,authenticating the data,consumer and service

examples for this category are Data Confidentiality, Data Origin Authentication, Direct Authentication, Brokered Authentication

[http://www.soapatterns.org/masterlist_c.asp#ch21 Transformation Patterns]

The Patterns proposed in this category concrete on how data from one data model can be dynamically converted to comply to a different data model.

examples for this category are Data Model Transformation,Data Format Transformation, Protocol Bridging

[http://www.soapatterns.org/masterlist_c.asp#ch22 Common Compound Design Patterns]

A compound pattern is a coarse-grained pattern comprised of a set of finer-grained patterns.

examples for this category are Orchestration,Enterprise Service Bus,Service Broker,Canonical Schema Bus,Official Endpoint,Federated Endpoint Layer,Three-Layer Inventory

=Example Design Patterns =

The following section describes five design patterns which are utilized in SOA.The described patterns provide the problem and corresponding solution

==Canonical protocol==

[[Image:Canonicalpattern.jpg.png]]

Problem: Services that support different communication technologies compromise interoperability, limit the quantity of potential consumers, and introduce the need for undesirable protocol bridging measures.

Solution: The architecture establishes a single communications technology as the sole or primary medium by which services can interact.

From the above figure it is observed that the services are delivered by three different communication technologies A,B and C.These services are made to conform to one centralized communications technology, making them technologically compatible.with this these services can be delivered to consumers without much difficulty

==Dual protocol==

[[Image:dualprotocol.png]]

Problem: Canonical Protocol requires that all services conform to the use of the same communications technology; however, a single protocol may not be able to accommodate all service requirements, thereby introducing limitations.

Solution: The service inventory architecture is designed to support services based on primary and secondary protocols.

Regardless of protocol, all services must invoke each other via their official service contracts (A, B). Bypassing the contract may seem convenient when the underlying service logic of the primary service supports the same protocol as the secondary service (C), but it is an anti-pattern that will eventually inhibit the application of this pattern and further weaken the overall service inventory foundation.

==Protocol Bridging==

[[Image:protocolbridging.png]]

Problem: Services using different communication protocols or different versions of the same protocol cannot exchange data.

Solution: Bridging logic is introduced to enable communication between different communication protocols by dynamically converting one protocol to another at runtime.

From the above figure it can be noticed that the consumer programs interact with a middle-tier broker that provides protocol bridging features. Separate protocol adapters are used to translate the two incompatible protocols to the required SOAP version 1.2 over HTTP. The broker then transmits the messages to the service on behalf of the consumers.

==UI Mediator==

[[Image:uimediator.png]]

Problem: Because the behavior of individual services can vary depending on their design,runtime usage, and the workload required to carry out a given capability, the consistency with which a service-oriented solution can respond to requests originating from a user-interface can fluctuate, leading to a poor user experience.

Solution: Establish mediator logic solely responsible for ensuring timely interaction and feedback with user-interfaces and presentation logic.

The mediator service (D) regularly updates the user interface while services A, B, and C work behind-the-scenes to complete the task

==Service Facade==

[[Image:service_facade.png]]

Problem: The coupling of the core service logic to contracts and implementation resources can inhibit its evolution and negatively impact service consumers.

Solution: A service facade component is used to abstract a part of the service architecture with negative coupling potential.

Facade logic is placed in between the contract and the core service logic. This allows the core service logic to remain decoupled from the contract.

=Similarities and Differences Between Patterns for SOA and Traditional pattens proposed by GoF=

The Gang of Four(Gof) comprising of Eric Gamma, Richard Helm, Ralph Johnson, and John Vlissides have documented the design patterns that were followed by Software developers and architects in object oriented space. They have documented 23 design patterns which are collectively called as Traditional design patterns.

The design patterns in SOA are similiar in some aspects to the traditional patterns.They also differ from the traditional patterns. The similiarities and differences between them are provided in this section

==Differences==

The differences between the SOA design patterns and traditional design patterns have been come up based on the individual functionality that each pattern provide. Following are the differences,

1) The composite pattern organizes the objects in the manner to represent the part-whole hierarchies in a traditional two-tier hierarchy.

The [http://www.soapatterns.org/agnostic_subcontroller.asp agnostic sub-controller] implements the service composability but it differs from the composite pattern in such a way that cross-entity functionality is abstracted and made accessible through the sub –controller capability.

For instance, the traditional composite pattern has the object representing a part-whole hierarchy as in the below figure of graphic class which has draw(). If we require a cross-entity functionality as in the below figure, we require a colored rectangle, we require the functionality fill() of color class. Hence the sub-controller module is created which has the functionality of different parents, thus making it reusable.

figure to illustrate above difference

[[Image:Composite_example.png]]

2)
The traditional bridge pattern separates the abstraction from its implementation in order to vary independently. Whereas the canonical protocol avoids the protocol bridging in such a way that there is a single communication technology through which the services can interact.
In the below figure of bridge pattern, the relationship between the abstraction and implementor is bridge and it results the implementor to vary independently from the abstraction by having different ConcreteImplementor. The canonical protocol avoids the variation by having a single communication technology between different objects.

figure for above difference

[[Image:Traditional_bridge.png]]
Figure for Traditional bridge pattern

For canonical protocol refer to the explanation given in example design patterns

3) The traditional builder pattern decouples the construction of the object from its representation so that the same construction process can be used to develop different representations. The different representations (contracts) are addressed in SOA by the Concurrent Contracts with the application of Service-façade design pattern. With service-façade design pattern, an abstraction is created to support the interaction between different contracts. As a result, different contracts can be created for a single service.
In the below figure, the conversion of the text document is separated from the reader of RTF document, so that the text document can be represented in different forms like ASCIIText, TeXText and TextWidget. The different representation is achieved by decoupling of construction and abstraction. In the case of concurrent contracts pattern, the different contracts or services (invoices) are created for different consumer through service-façade by creating a new abstraction.

[[Image:Builder.png]]
Figure for Traditional Builder pattern

[[Image:Concurrent_pattern.png]]
Figure for Concurrent pattern

==Similarities==
1) The Service-façade design pattern is similar to the façade (traditional) pattern in the manner that it implements the façade logic which is creating an abstraction for intra-communication within objects to the service architecture. The advantage by adding the façade logic to the service architecture is that it preserves the underlying logic from run-time changes.

2) The UI Mediator design pattern implements the mediator logic of traditional mediator pattern. The mediator logic aims to provide the user responses in a way that user understands, independently of what the underlying services perform.

3) The Intermediate routing pattern in SOA is similar to Decorator pattern (traditional) in the functionality that it adds the required logic at run-time. The decorator adds the additional functionality to the object at run-time. The intermediate routing pattern is about placing the routing logic to address the run-time scenarios.

4)The Capability Composition pattern in SOA implements the Composite pattern (traditional). The Capability Composition is about composing one or more capabilities outside the service’s context to address the large, complex problem.

5) The Decoupled Contract pattern implements the traditional Bridge pattern in the manner that service contract is separated from the implementation. The Bridge pattern decouples the abstraction from implementation to facilitate the variation of both (abstraction and implementation).

6) The Legacy Wrapper pattern is related to traditional Adapter pattern. The Legacy Wrapper pattern protects the legacy logic by providing a standard service that takes of protecting the legacy details by encapsulating, extraction or elimination. The encapsulation, extraction or elimination is done in order to change the service as the consumer requires it. This is related to adapter in a way that it converts the interface of one class to another as the client expects.

=Summary=

=Glossary=

1.Serive : "A service is a discoverable resource that executes a repeatable task, and is described by an externalized service specification."

2.[http://www.ibm.com/developerworks/webservices/library/ws-soa-term1/ SOA Terminology]

3.SOA :[http://en.wikipedia.org/wiki/Service-oriented_architecture Service oriented Architecture]

4.API :[http://en.wikipedia.org/wiki/Application_programming_interface Application programming interface]

5.SOAP :[http://en.wikipedia.org/wiki/SOAP Simple Object Access Protocol]

6.HTTP :[http://en.wikipedia.org/wiki/HyperText_Transfer_Protocol Hypertext Transfer Protocol]

7.GoF :[http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Gang of Four]

8.[http://soaglossary.com/ SOA Glossory]

=References=

1.[http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Design patterns for object oriented software]

2.[http://en.wikipedia.org/wiki/Service-oriented_architecture#Introduction Service Oriented Architecture]

3.[http://www.exforsys.com/tutorials/soa/soa-definitions-and-certification.html SOA Tutorial]

4.[http://www.soapatterns.org/ soa design patterns]

5.[http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29 design pattern]

6.[http://www.oracle.com/technologies/soa/center.html oracle SOA centre]

7.[http://www.ibm.com/developerworks/webservices/library/ws-soa-term1/ IBMs SOA Contributions]

8.[http://www.oracle.com/technology/pub/articles/erl_soa_design_patterns_app_sequences.html SOA Design patterns application sequences by oracle]

CSC/ECE 517 Fall 2009/wiki2 16 rs

2009-10-10T02:44:24Z

Screenit: /* SOA-Benifits */

CSC/ECE 517 Fall 2009/wiki2 16 rs

SOA provides another view of providing functionality based upon services offered in terms of protocols and a specific API. Research and report on what patterns have been proposed and are utilized within this domain. How do they differ from traditional design patterns proposed by Eric Gamma, Richard Helm, Ralph Johnson, and John Vlissides? How are they similar?

----
=Introduction=

This article focuses on the design patterns which are proposed and utilized in the [http://en.wikipedia.org/wiki/Service_oriented_architecture Service Oriented Architecture]. As the SOA provides its services through the protocols and API, this article throws light on the design patterns that specifically provide services through protocols like [http://www.soapatterns.org/canonical_protocol.asp Canonical protocol], [http://www.soapatterns.org/dual_protocols.asp Dual protocols] and [http://www.soapatterns.org/protocol_bridging.asp Protocol Bridging]. In a broader perspective, other design patterns have been explained tersely. In addition to explanation of the SOA design patterns, this compares the SOA design patterns with the traditional design patterns proposed by the ‘Gang of Four’ (Eric Gamma, Richard Helm, Ralph Johnson, and John Vlissides) and comes up with the differences and similarities between them.

=Service Oriented Architecture-An Overview=

==SOA-Definition==

A [http://en.wikipedia.org/wiki/Service_oriented_architecture Service Oriented Architecture] is an architecture that provides collection of services. These services need to inter-operate with each other to provide the functionality. This architecture requires a loose coupling with operating systems and other technologies that form the basis of the application. The loose coupling between services is required because each interaction has to be independent of the other. The communication between services could be either simple data being passed or it could be either an activity coordinated between distinct entities or services. Some means of interoperability is required to provide the services in larger terms. Instead of defining the API, the SOA implements the interfaces using the protocols and functionality. SOA separates functions into unique entities or services, which are accessed in a network by the users to combine and reuse them to develop the applications.

==Why SOA?==

Various businesses in the field of [http://en.wikipedia.org/wiki/Information_technology Information Technology] have to justify their projects with a return on their investments. This creates a pressure in Information Technology by making it a demanding field. Information Technology needs to have requirements in a way that it has to responsive and adapt to the changing requirements.

Information Technology companies must also be able to provide the services that are compatible with other services making it interoperable, thus creating dynamic services. Moreover, Information Technology has to face demands to bring new commercial services to a much wider array of customers. Customers may access services through web interfaces, or may be part of a supply chain that needs to decrease the time and cost of manufacturing.

Thus, Information Technology companies are always on the look out for solutions that will help them meet the above demands – without having to spend a lot of money. [http://en.wikipedia.org/wiki/Service_oriented_architecture Service Oriented Architecture] offers a solution to satisfy the above needs of the industry

==SOA-Benifits==
In architectural terms, a modern architectural design should be Service Oriented, loosely coupled, driven by events, able to support both integration and assembly, aligned with valuable life cycle support processes, and able to leverage existing infrastructure and applications.

When it comes to Service Oriented Architecture, it tends to offer a variety of different advantages over more traditional methods of distributing computing. These include
i) business services across several platforms
ii) location independence
iii) authentication as well as authorization support on different platforms
iv ) loosely coupled approach, dynamic search and connectivity to other services.

=Design Patterns in SOA=
A design pattern is a general reusable solution to a commonly occurring problem in software design. A design pattern is not a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations.Design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved.

Design patterns play a major role in SOA. The implementation and deployment of SOA designs provide different challenges during product development life cycle.Such challenges made may SOA projects to be discontinued. Design patterns help in overcoming these problems by providing a solution to the problems posed.Each SOA design pattern provides a design solution in support of
successfully applying service orientation and establishing a quality
service-oriented architecture

=Design Patterns proposed =

The proposed Design Patterns for SOA fall in to following categories.They are listed below and corresponding patterns in
each category are given.

[http://www.soapatterns.org/masterlist_c.asp#ch6 Foundational Inventory Patterns]

These design patterns focus on providing solutions to the problems like maximizing re-composition and avoiding redundant logic .

examples for this category are Enterprise Inventory,Domain Inventory,Service Normalization,Logic Centralization, Service Layers Canonical Protocol,Canonical Schema

[http://www.soapatterns.org/masterlist_c.asp#ch7 Logical Inventory Layer Patterns]

These design patterns provide the solution to the problem of how can business logic be separated, reused, and governed independently?

examples for this category are Utility Abstraction,Entity Abstraction,Process Abstraction

[http://www.soapatterns.org/masterlist_c.asp#ch8 Inventory Centralization Patterns]

These patterns focus on providing solution for aspect of governing business logic etc

examples for this category are Process Centralization,Schema Centralization,Policy Centralization,Rules Centralization.

[http://www.soapatterns.org/masterlist_c.asp#ch9 Inventory Implementation Patterns]

These patterns help to solve implementation problems like limitations introduced by communication technology. Example like a single protocol may not accommodate all requirements etc

examples for this category are Dual Protocols,Canonical Resources,State Repository,Stateful Services,Service Grid,Inventory Endpoint,Cross-Domain Utility Layer

[http://www.soapatterns.org/masterlist_c.asp#ch10 Inventory Governance Patterns]

The patterns deal with the governance problems caused by service contract within the same service inventory

examples for this category are Canonical Expression,Metadata Centralization,Canonical Versioning

[http://www.soapatterns.org/masterlist_c.asp#ch11 Foundational Service Patterns]

The patterns proposed in this category focus on solving large business problems without having to build a stand alone solution.

examples for this category are Functional Decomposition,Service Encapsulation,Agnostic Context,Non-Agnostic Context,Agnostic Capability

[http://www.soapatterns.org/masterlist_c.asp#ch12 Service Implementation Patterns]

The patterns in this category focus on improving the realiability and availability of the service

examples for this category are Service Facade,Redundant Implementation,Service Data Replication,Partial State Deferral,Partial Validation,UI Mediator

[http://www.soapatterns.org/masterlist_c.asp#ch13 Service Security Patterns]

The patterns proposed in this category deal with the problem of data encapsulation and security aspects.

examples for this category are Exception Shielding,Message Screening,Trusted Subsystem ,Service Perimeter Guard

[http://www.soapatterns.org/masterlist_c.asp#ch14 Service Contract Design Patterns]

The patterns proposed in this category focus on providing solution for how to make the service contract suitable for all potential customers,make it aligned with other services etc

examples for this category are Decoupled Contract,Contract Centralization,Contract De normalization,Concurrent Contracts,Validation Abstraction

[http://www.soapatterns.org/masterlist_c.asp#ch15 Legacy Encapsulation Patterns]

The patterns proposed deals with the problems in legacy systems like processing of data contained in flat files, redundancy resulting in delivery to multiple channels etc

examples for this category are Legacy Wrapper, Multi-Channel Endpoint,File Gateway

[http://www.soapatterns.org/masterlist_c.asp#ch16 Service Governance Patterns]

These patterns provide solution for problems like updating the customers with changed service so that they are not affected, modifications in service etc

examples for this category are Compatible Change,Version Identification,Termination Notification,Service Refactoring,Service Decomposition,Proxy Capability,Decomposed Capability,Distributed Capability

[http://www.soapatterns.org/masterlist_c.asp#ch17 Capability Composition Patterns]

The pattern proposed focuses on the problem of How can a service capability solve a problem that requires logic outside of the service boundary and How can the same capability be used to help solve multiple problems?

examples for this category are Capability Composition,Capability Recomposition

[http://www.soapatterns.org/masterlist_c.asp#ch18 Service Messaging Patterns]

The patterns proposed in this category focus on setting up of message framework for transfer of data.

examples in this category are Service Messaging,Messaging Metadata,Service Agent,Intermediate Routing,State Messaging,Service Callback,Service Instance Routing,Asynchronous Queuing,Reliable Messaging,Event-Driven Messaging.

[http://www.soapatterns.org/masterlist_c.asp#ch19 Composition Implementation Patterns]

The patterns proposed in this category focus on problems during runtime like runtime activities that span multiple services fail, the parent business task is incomplete etc

examples for this category are Agnostic SubController,Composition Autonomy,Atomic Service Transaction,Compensating ServiceTransaction

[http://www.soapatterns.org/masterlist_c.asp#ch20 Service Interaction Security Patterns]

The proposed patterns in this category are focused on security methods like encryption,decryption,authenticating the data,consumer and service

examples for this category are Data Confidentiality, Data Origin Authentication, Direct Authentication, Brokered Authentication

[http://www.soapatterns.org/masterlist_c.asp#ch21 Transformation Patterns]

The Patterns proposed in this category concrete on how data from one data model can be dynamically converted to comply to a different data model.

examples for this category are Data Model Transformation,Data Format Transformation, Protocol Bridging

[http://www.soapatterns.org/masterlist_c.asp#ch22 Common Compound Design Patterns]

A compound pattern is a coarse-grained pattern comprised of a set of finer-grained patterns.

examples for this category are Orchestration,Enterprise Service Bus,Service Broker,Canonical Schema Bus,Official Endpoint,Federated Endpoint Layer,Three-Layer Inventory

=Example Design Patterns =

The following section describes five design patterns which are utilized in SOA.The described patterns provide the problem and corresponding solution

==Canonical protocol==

[[Image:Canonicalpattern.jpg.png]]

Problem: Services that support different communication technologies compromise interoperability, limit the quantity of potential consumers, and introduce the need for undesirable protocol bridging measures.

Solution: The architecture establishes a single communications technology as the sole or primary medium by which services can interact.

From the above figure it is observed that though still delivered by different projects via different vendor platforms A,B,C etc these services conform to one centralized communications technology, making them technologically compatible.

==Dual protocol==

[[Image:dualprotocol.png]]

Problem: Canonical Protocol requires that all services conform to the use of the same communications technology; however, a single protocol may not be able to accommodate all service requirements, thereby introducing limitations.

Solution: The service inventory architecture is designed to support services based on primary and secondary protocols.

Regardless of protocol, all services must invoke each other via their official service contracts (A, B). Bypassing the contract may seem convenient when the underlying service logic of the primary service supports the same protocol as the secondary service (C), but it is an anti-pattern that will eventually inhibit the application of this pattern and further weaken the overall service inventory foundation.

==Protocol Bridging==

[[Image:protocolbridging.png]]

Problem: Services using different communication protocols or different versions of the same protocol cannot exchange data.

Solution: Bridging logic is introduced to enable communication between different communication protocols by dynamically converting one protocol to another at runtime.

From the above figure it can be noticed that the consumer programs interact with a middle-tier broker that provides protocol bridging features. Separate protocol adapters are used to translate the two incompatible protocols to the required SOAP version 1.2 over HTTP. The broker then transmits the messages to the service on behalf of the consumers.

==UI Mediator==

[[Image:uimediator.png]]

Problem: Because the behavior of individual services can vary depending on their design,runtime usage, and the workload required to carry out a given capability, the consistency with which a service-oriented solution can respond to requests originating from a user-interface can fluctuate, leading to a poor user experience.

Solution: Establish mediator logic solely responsible for ensuring timely interaction and feedback with user-interfaces and presentation logic.

The mediator service (D) regularly updates the user interface while services A, B, and C work behind-the-scenes to complete the task

==Service Facade==

[[Image:service_facade.png]]

Problem: The coupling of the core service logic to contracts and implementation resources can inhibit its evolution and negatively impact service consumers.

Solution: A service facade component is used to abstract a part of the service architecture with negative coupling potential.

Facade logic is placed in between the contract and the core service logic. This allows the core service logic to remain decoupled from the contract.

=Similarities and Differences Between Patterns for SOA and Traditional pattens proposed by GoF=

The Gang of Four(Gof) comprising of Eric Gamma, Richard Helm, Ralph Johnson, and John Vlissides have documented the design patterns that were followed by Software developers and architects in object oriented space. They have documented 23 design patterns which are collectively called as Traditional design patterns.

The design patterns in SOA are similiar in some aspects to the traditional patterns.They also differ from the traditional patterns. The similiarities and differences between them are provided in this section

==Differences==

The differences between the SOA design patterns and traditional design patterns have been come up based on the individual functionality that each pattern provide. Following are the differences,

1) The composite pattern organizes the objects in the manner to represent the part-whole hierarchies in a traditional two-tier hierarchy.

The [http://www.soapatterns.org/agnostic_subcontroller.asp agnostic sub-controller] implements the service composability but it differs from the composite pattern in such a way that cross-entity functionality is abstracted and made accessible through the sub –controller capability.

For instance, the traditional composite pattern has the object representing a part-whole hierarchy as in the below figure of graphic class which has draw(). If we require a cross-entity functionality as in the below figure, we require a colored rectangle, we require the functionality fill() of color class. Hence the sub-controller module is created which has the functionality of different parents, thus making it reusable.

figure to illustrate above difference

[[Image:Composite_example.png]]

2)
The traditional bridge pattern separates the abstraction from its implementation in order to vary independently. Whereas the canonical protocol avoids the protocol bridging in such a way that there is a single communication technology through which the services can interact.
In the below figure of bridge pattern, the relationship between the abstraction and implementor is bridge and it results the implementor to vary independently from the abstraction by having different ConcreteImplementor. The canonical protocol avoids the variation by having a single communication technology between different objects.

figure for above difference

[[Image:Traditional_bridge.png]]
Figure for Traditional bridge pattern

For canonical protocol refer to the explanation given in example design patterns

3) The traditional builder pattern decouples the construction of the object from its representation so that the same construction process can be used to develop different representations. The different representations (contracts) are addressed in SOA by the Concurrent Contracts with the application of Service-façade design pattern. With service-façade design pattern, an abstraction is created to support the interaction between different contracts. As a result, different contracts can be created for a single service.
In the below figure, the conversion of the text document is separated from the reader of RTF document, so that the text document can be represented in different forms like ASCIIText, TeXText and TextWidget. The different representation is achieved by decoupling of construction and abstraction. In the case of concurrent contracts pattern, the different contracts or services (invoices) are created for different consumer through service-façade by creating a new abstraction.

[[Image:Builder.png]]
Figure for Traditional Builder pattern

[[Image:Concurrent_pattern.png]]
Figure for Concurrent pattern

==Similarities==
1) The Service-façade design pattern is similar to the façade (traditional) pattern in the manner that it implements the façade logic which is creating an abstraction for intra-communication within objects to the service architecture. The advantage by adding the façade logic to the service architecture is that it preserves the underlying logic from run-time changes.

2) The UI Mediator design pattern implements the mediator logic of traditional mediator pattern. The mediator logic aims to provide the user responses in a way that user understands, independently of what the underlying services perform.

3) The Intermediate routing pattern in SOA is similar to Decorator pattern (traditional) in the functionality that it adds the required logic at run-time. The decorator adds the additional functionality to the object at run-time. The intermediate routing pattern is about placing the routing logic to address the run-time scenarios.

4)The Capability Composition pattern in SOA implements the Composite pattern (traditional). The Capability Composition is about composing one or more capabilities outside the service’s context to address the large, complex problem.

5) The Decoupled Contract pattern implements the traditional Bridge pattern in the manner that service contract is separated from the implementation. The Bridge pattern decouples the abstraction from implementation to facilitate the variation of both (abstraction and implementation).

6) The Legacy Wrapper pattern is related to traditional Adapter pattern. The Legacy Wrapper pattern protects the legacy logic by providing a standard service that takes of protecting the legacy details by encapsulating, extraction or elimination. The encapsulation, extraction or elimination is done in order to change the service as the consumer requires it. This is related to adapter in a way that it converts the interface of one class to another as the client expects.

=Summary=

=Glossary=

1.Serive : "A service is a discoverable resource that executes a repeatable task, and is described by an externalized service specification."

2.[http://www.ibm.com/developerworks/webservices/library/ws-soa-term1/ SOA Terminology]

3.SOA :[http://en.wikipedia.org/wiki/Service-oriented_architecture Service oriented Architecture]

4.API :[http://en.wikipedia.org/wiki/Application_programming_interface Application programming interface]

5.SOAP :[http://en.wikipedia.org/wiki/SOAP Simple Object Access Protocol]

6.HTTP :[http://en.wikipedia.org/wiki/HyperText_Transfer_Protocol Hypertext Transfer Protocol]

7.GoF :[http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Gang of Four]

8.[http://soaglossary.com/ SOA Glossory]

=References=

1.[http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Design patterns for object oriented software]

2.[http://en.wikipedia.org/wiki/Service-oriented_architecture#Introduction Service Oriented Architecture]

3.[http://www.exforsys.com/tutorials/soa/soa-definitions-and-certification.html SOA Tutorial]

4.[http://www.soapatterns.org/ soa design patterns]

5.[http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29 design pattern]

6.[http://www.oracle.com/technologies/soa/center.html oracle SOA centre]

7.[http://www.ibm.com/developerworks/webservices/library/ws-soa-term1/ IBMs SOA Contributions]

8.[http://www.oracle.com/technology/pub/articles/erl_soa_design_patterns_app_sequences.html SOA Design patterns application sequences by oracle]

CSC/ECE 517 Fall 2009/wiki2 16 rs

2009-10-10T02:39:28Z

Screenit: /* Why SOA? */

CSC/ECE 517 Fall 2009/wiki2 16 rs

SOA provides another view of providing functionality based upon services offered in terms of protocols and a specific API. Research and report on what patterns have been proposed and are utilized within this domain. How do they differ from traditional design patterns proposed by Eric Gamma, Richard Helm, Ralph Johnson, and John Vlissides? How are they similar?

----
=Introduction=

This article focuses on the design patterns which are proposed and utilized in the [http://en.wikipedia.org/wiki/Service_oriented_architecture Service Oriented Architecture]. As the SOA provides its services through the protocols and API, this article throws light on the design patterns that specifically provide services through protocols like [http://www.soapatterns.org/canonical_protocol.asp Canonical protocol], [http://www.soapatterns.org/dual_protocols.asp Dual protocols] and [http://www.soapatterns.org/protocol_bridging.asp Protocol Bridging]. In a broader perspective, other design patterns have been explained tersely. In addition to explanation of the SOA design patterns, this compares the SOA design patterns with the traditional design patterns proposed by the ‘Gang of Four’ (Eric Gamma, Richard Helm, Ralph Johnson, and John Vlissides) and comes up with the differences and similarities between them.

=Service Oriented Architecture-An Overview=

==SOA-Definition==

A [http://en.wikipedia.org/wiki/Service_oriented_architecture Service Oriented Architecture] is an architecture that provides collection of services. These services need to inter-operate with each other to provide the functionality. This architecture requires a loose coupling with operating systems and other technologies that form the basis of the application. The loose coupling between services is required because each interaction has to be independent of the other. The communication between services could be either simple data being passed or it could be either an activity coordinated between distinct entities or services. Some means of interoperability is required to provide the services in larger terms. Instead of defining the API, the SOA implements the interfaces using the protocols and functionality. SOA separates functions into unique entities or services, which are accessed in a network by the users to combine and reuse them to develop the applications.

==Why SOA?==

Various businesses in the field of [http://en.wikipedia.org/wiki/Information_technology Information Technology] have to justify their projects with a return on their investments. This creates a pressure in Information Technology by making it a demanding field. Information Technology needs to have requirements in a way that it has to responsive and adapt to the changing requirements.

Information Technology companies must also be able to provide the services that are compatible with other services making it interoperable, thus creating dynamic services. Moreover, Information Technology has to face demands to bring new commercial services to a much wider array of customers. Customers may access services through web interfaces, or may be part of a supply chain that needs to decrease the time and cost of manufacturing.

Thus, Information Technology companies are always on the look out for solutions that will help them meet the above demands – without having to spend a lot of money. [http://en.wikipedia.org/wiki/Service_oriented_architecture Service Oriented Architecture] offers a solution to satisfy the above needs of the industry

==SOA-Benifits==
In architectural terms, a modern architectural design should be Service Oriented, loosely coupled, driven by events, able to support both integration and assembly, aligned with valuable life cycle support processes, and able to leverage existing infrastructure and applications.

When it comes to Service Oriented Architecture, it tends to offer a variety of different advantages over more traditional methods of distributing computing. These include offering business services across several platforms; providing location independence; providing authentication as well as authorization support on ever tier; a loosely coupled approach; and dynamic search and connectivity to other services. At the same time, it allows that services do not have to be located on a particular system or network.

=Design Patterns in SOA=
A design pattern is a general reusable solution to a commonly occurring problem in software design. A design pattern is not a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations.Design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved.

Design patterns play a major role in SOA. The implementation and deployment of SOA designs provide different challenges during product development life cycle.Such challenges made may SOA projects to be discontinued. Design patterns help in overcoming these problems by providing a solution to the problems posed.Each SOA design pattern provides a design solution in support of
successfully applying service orientation and establishing a quality
service-oriented architecture

=Design Patterns proposed =

The proposed Design Patterns for SOA fall in to following categories.They are listed below and corresponding patterns in
each category are given.

[http://www.soapatterns.org/masterlist_c.asp#ch6 Foundational Inventory Patterns]

These design patterns focus on providing solutions to the problems like maximizing re-composition and avoiding redundant logic .

examples for this category are Enterprise Inventory,Domain Inventory,Service Normalization,Logic Centralization, Service Layers Canonical Protocol,Canonical Schema

[http://www.soapatterns.org/masterlist_c.asp#ch7 Logical Inventory Layer Patterns]

These design patterns provide the solution to the problem of how can business logic be separated, reused, and governed independently?

examples for this category are Utility Abstraction,Entity Abstraction,Process Abstraction

[http://www.soapatterns.org/masterlist_c.asp#ch8 Inventory Centralization Patterns]

These patterns focus on providing solution for aspect of governing business logic etc

examples for this category are Process Centralization,Schema Centralization,Policy Centralization,Rules Centralization.

[http://www.soapatterns.org/masterlist_c.asp#ch9 Inventory Implementation Patterns]

These patterns help to solve implementation problems like limitations introduced by communication technology. Example like a single protocol may not accommodate all requirements etc

examples for this category are Dual Protocols,Canonical Resources,State Repository,Stateful Services,Service Grid,Inventory Endpoint,Cross-Domain Utility Layer

[http://www.soapatterns.org/masterlist_c.asp#ch10 Inventory Governance Patterns]

The patterns deal with the governance problems caused by service contract within the same service inventory

examples for this category are Canonical Expression,Metadata Centralization,Canonical Versioning

[http://www.soapatterns.org/masterlist_c.asp#ch11 Foundational Service Patterns]

The patterns proposed in this category focus on solving large business problems without having to build a stand alone solution.

examples for this category are Functional Decomposition,Service Encapsulation,Agnostic Context,Non-Agnostic Context,Agnostic Capability

[http://www.soapatterns.org/masterlist_c.asp#ch12 Service Implementation Patterns]

The patterns in this category focus on improving the realiability and availability of the service

examples for this category are Service Facade,Redundant Implementation,Service Data Replication,Partial State Deferral,Partial Validation,UI Mediator

[http://www.soapatterns.org/masterlist_c.asp#ch13 Service Security Patterns]

The patterns proposed in this category deal with the problem of data encapsulation and security aspects.

examples for this category are Exception Shielding,Message Screening,Trusted Subsystem ,Service Perimeter Guard

[http://www.soapatterns.org/masterlist_c.asp#ch14 Service Contract Design Patterns]

The patterns proposed in this category focus on providing solution for how to make the service contract suitable for all potential customers,make it aligned with other services etc

examples for this category are Decoupled Contract,Contract Centralization,Contract De normalization,Concurrent Contracts,Validation Abstraction

[http://www.soapatterns.org/masterlist_c.asp#ch15 Legacy Encapsulation Patterns]

The patterns proposed deals with the problems in legacy systems like processing of data contained in flat files, redundancy resulting in delivery to multiple channels etc

examples for this category are Legacy Wrapper, Multi-Channel Endpoint,File Gateway

[http://www.soapatterns.org/masterlist_c.asp#ch16 Service Governance Patterns]

These patterns provide solution for problems like updating the customers with changed service so that they are not affected, modifications in service etc

examples for this category are Compatible Change,Version Identification,Termination Notification,Service Refactoring,Service Decomposition,Proxy Capability,Decomposed Capability,Distributed Capability

[http://www.soapatterns.org/masterlist_c.asp#ch17 Capability Composition Patterns]

The pattern proposed focuses on the problem of How can a service capability solve a problem that requires logic outside of the service boundary and How can the same capability be used to help solve multiple problems?

examples for this category are Capability Composition,Capability Recomposition

[http://www.soapatterns.org/masterlist_c.asp#ch18 Service Messaging Patterns]

The patterns proposed in this category focus on setting up of message framework for transfer of data.

examples in this category are Service Messaging,Messaging Metadata,Service Agent,Intermediate Routing,State Messaging,Service Callback,Service Instance Routing,Asynchronous Queuing,Reliable Messaging,Event-Driven Messaging.

[http://www.soapatterns.org/masterlist_c.asp#ch19 Composition Implementation Patterns]

The patterns proposed in this category focus on problems during runtime like runtime activities that span multiple services fail, the parent business task is incomplete etc

examples for this category are Agnostic SubController,Composition Autonomy,Atomic Service Transaction,Compensating ServiceTransaction

[http://www.soapatterns.org/masterlist_c.asp#ch20 Service Interaction Security Patterns]

The proposed patterns in this category are focused on security methods like encryption,decryption,authenticating the data,consumer and service

examples for this category are Data Confidentiality, Data Origin Authentication, Direct Authentication, Brokered Authentication

[http://www.soapatterns.org/masterlist_c.asp#ch21 Transformation Patterns]

The Patterns proposed in this category concrete on how data from one data model can be dynamically converted to comply to a different data model.

examples for this category are Data Model Transformation,Data Format Transformation, Protocol Bridging

[http://www.soapatterns.org/masterlist_c.asp#ch22 Common Compound Design Patterns]

A compound pattern is a coarse-grained pattern comprised of a set of finer-grained patterns.

examples for this category are Orchestration,Enterprise Service Bus,Service Broker,Canonical Schema Bus,Official Endpoint,Federated Endpoint Layer,Three-Layer Inventory

=Example Design Patterns =

The following section describes five design patterns which are utilized in SOA.The described patterns provide the problem and corresponding solution

==Canonical protocol==

[[Image:Canonicalpattern.jpg.png]]

Problem: Services that support different communication technologies compromise interoperability, limit the quantity of potential consumers, and introduce the need for undesirable protocol bridging measures.

Solution: The architecture establishes a single communications technology as the sole or primary medium by which services can interact.

From the above figure it is observed that though still delivered by different projects via different vendor platforms A,B,C etc these services conform to one centralized communications technology, making them technologically compatible.

==Dual protocol==

[[Image:dualprotocol.png]]

Problem: Canonical Protocol requires that all services conform to the use of the same communications technology; however, a single protocol may not be able to accommodate all service requirements, thereby introducing limitations.

Solution: The service inventory architecture is designed to support services based on primary and secondary protocols.

Regardless of protocol, all services must invoke each other via their official service contracts (A, B). Bypassing the contract may seem convenient when the underlying service logic of the primary service supports the same protocol as the secondary service (C), but it is an anti-pattern that will eventually inhibit the application of this pattern and further weaken the overall service inventory foundation.

==Protocol Bridging==

[[Image:protocolbridging.png]]

Problem: Services using different communication protocols or different versions of the same protocol cannot exchange data.

Solution: Bridging logic is introduced to enable communication between different communication protocols by dynamically converting one protocol to another at runtime.

From the above figure it can be noticed that the consumer programs interact with a middle-tier broker that provides protocol bridging features. Separate protocol adapters are used to translate the two incompatible protocols to the required SOAP version 1.2 over HTTP. The broker then transmits the messages to the service on behalf of the consumers.

==UI Mediator==

[[Image:uimediator.png]]

Problem: Because the behavior of individual services can vary depending on their design,runtime usage, and the workload required to carry out a given capability, the consistency with which a service-oriented solution can respond to requests originating from a user-interface can fluctuate, leading to a poor user experience.

Solution: Establish mediator logic solely responsible for ensuring timely interaction and feedback with user-interfaces and presentation logic.

The mediator service (D) regularly updates the user interface while services A, B, and C work behind-the-scenes to complete the task

==Service Facade==

[[Image:service_facade.png]]

Problem: The coupling of the core service logic to contracts and implementation resources can inhibit its evolution and negatively impact service consumers.

Solution: A service facade component is used to abstract a part of the service architecture with negative coupling potential.

Facade logic is placed in between the contract and the core service logic. This allows the core service logic to remain decoupled from the contract.

=Similarities and Differences Between Patterns for SOA and Traditional pattens proposed by GoF=

The Gang of Four(Gof) comprising of Eric Gamma, Richard Helm, Ralph Johnson, and John Vlissides have documented the design patterns that were followed by Software developers and architects in object oriented space. They have documented 23 design patterns which are collectively called as Traditional design patterns.

The design patterns in SOA are similiar in some aspects to the traditional patterns.They also differ from the traditional patterns. The similiarities and differences between them are provided in this section

==Differences==

The differences between the SOA design patterns and traditional design patterns have been come up based on the individual functionality that each pattern provide. Following are the differences,

1) The composite pattern organizes the objects in the manner to represent the part-whole hierarchies in a traditional two-tier hierarchy.

The [http://www.soapatterns.org/agnostic_subcontroller.asp agnostic sub-controller] implements the service composability but it differs from the composite pattern in such a way that cross-entity functionality is abstracted and made accessible through the sub –controller capability.

For instance, the traditional composite pattern has the object representing a part-whole hierarchy as in the below figure of graphic class which has draw(). If we require a cross-entity functionality as in the below figure, we require a colored rectangle, we require the functionality fill() of color class. Hence the sub-controller module is created which has the functionality of different parents, thus making it reusable.

figure to illustrate above difference

[[Image:Composite_example.png]]

2)
The traditional bridge pattern separates the abstraction from its implementation in order to vary independently. Whereas the canonical protocol avoids the protocol bridging in such a way that there is a single communication technology through which the services can interact.
In the below figure of bridge pattern, the relationship between the abstraction and implementor is bridge and it results the implementor to vary independently from the abstraction by having different ConcreteImplementor. The canonical protocol avoids the variation by having a single communication technology between different objects.

figure for above difference

[[Image:Traditional_bridge.png]]
Figure for Traditional bridge pattern

For canonical protocol refer to the explanation given in example design patterns

3) The traditional builder pattern decouples the construction of the object from its representation so that the same construction process can be used to develop different representations. The different representations (contracts) are addressed in SOA by the Concurrent Contracts with the application of Service-façade design pattern. With service-façade design pattern, an abstraction is created to support the interaction between different contracts. As a result, different contracts can be created for a single service.
In the below figure, the conversion of the text document is separated from the reader of RTF document, so that the text document can be represented in different forms like ASCIIText, TeXText and TextWidget. The different representation is achieved by decoupling of construction and abstraction. In the case of concurrent contracts pattern, the different contracts or services (invoices) are created for different consumer through service-façade by creating a new abstraction.

[[Image:Builder.png]]
Figure for Traditional Builder pattern

[[Image:Concurrent_pattern.png]]
Figure for Concurrent pattern

==Similarities==
1) The Service-façade design pattern is similar to the façade (traditional) pattern in the manner that it implements the façade logic which is creating an abstraction for intra-communication within objects to the service architecture. The advantage by adding the façade logic to the service architecture is that it preserves the underlying logic from run-time changes.

2) The UI Mediator design pattern implements the mediator logic of traditional mediator pattern. The mediator logic aims to provide the user responses in a way that user understands, independently of what the underlying services perform.

3) The Intermediate routing pattern in SOA is similar to Decorator pattern (traditional) in the functionality that it adds the required logic at run-time. The decorator adds the additional functionality to the object at run-time. The intermediate routing pattern is about placing the routing logic to address the run-time scenarios.

4)The Capability Composition pattern in SOA implements the Composite pattern (traditional). The Capability Composition is about composing one or more capabilities outside the service’s context to address the large, complex problem.

5) The Decoupled Contract pattern implements the traditional Bridge pattern in the manner that service contract is separated from the implementation. The Bridge pattern decouples the abstraction from implementation to facilitate the variation of both (abstraction and implementation).

6) The Legacy Wrapper pattern is related to traditional Adapter pattern. The Legacy Wrapper pattern protects the legacy logic by providing a standard service that takes of protecting the legacy details by encapsulating, extraction or elimination. The encapsulation, extraction or elimination is done in order to change the service as the consumer requires it. This is related to adapter in a way that it converts the interface of one class to another as the client expects.

=Summary=

=Glossary=

1.Serive : "A service is a discoverable resource that executes a repeatable task, and is described by an externalized service specification."

2.[http://www.ibm.com/developerworks/webservices/library/ws-soa-term1/ SOA Terminology]

3.SOA :[http://en.wikipedia.org/wiki/Service-oriented_architecture Service oriented Architecture]

4.API :[http://en.wikipedia.org/wiki/Application_programming_interface Application programming interface]

5.SOAP :[http://en.wikipedia.org/wiki/SOAP Simple Object Access Protocol]

6.HTTP :[http://en.wikipedia.org/wiki/HyperText_Transfer_Protocol Hypertext Transfer Protocol]

7.GoF :[http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Gang of Four]

8.[http://soaglossary.com/ SOA Glossory]

=References=

1.[http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Design patterns for object oriented software]

2.[http://en.wikipedia.org/wiki/Service-oriented_architecture#Introduction Service Oriented Architecture]

3.[http://www.exforsys.com/tutorials/soa/soa-definitions-and-certification.html SOA Tutorial]

4.[http://www.soapatterns.org/ soa design patterns]

5.[http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29 design pattern]

6.[http://www.oracle.com/technologies/soa/center.html oracle SOA centre]

7.[http://www.ibm.com/developerworks/webservices/library/ws-soa-term1/ IBMs SOA Contributions]

8.[http://www.oracle.com/technology/pub/articles/erl_soa_design_patterns_app_sequences.html SOA Design patterns application sequences by oracle]

CSC/ECE 517 Fall 2009/wiki2 16 rs

2009-10-10T02:26:16Z

Screenit: /* SOA-Definition */

CSC/ECE 517 Fall 2009/wiki2 16 rs

SOA provides another view of providing functionality based upon services offered in terms of protocols and a specific API. Research and report on what patterns have been proposed and are utilized within this domain. How do they differ from traditional design patterns proposed by Eric Gamma, Richard Helm, Ralph Johnson, and John Vlissides? How are they similar?

----
=Introduction=

This article focuses on the design patterns which are proposed and utilized in the [http://en.wikipedia.org/wiki/Service_oriented_architecture Service Oriented Architecture]. As the SOA provides its services through the protocols and API, this article throws light on the design patterns that specifically provide services through protocols like [http://www.soapatterns.org/canonical_protocol.asp Canonical protocol], [http://www.soapatterns.org/dual_protocols.asp Dual protocols] and [http://www.soapatterns.org/protocol_bridging.asp Protocol Bridging]. In a broader perspective, other design patterns have been explained tersely. In addition to explanation of the SOA design patterns, this compares the SOA design patterns with the traditional design patterns proposed by the ‘Gang of Four’ (Eric Gamma, Richard Helm, Ralph Johnson, and John Vlissides) and comes up with the differences and similarities between them.

=Service Oriented Architecture-An Overview=

==SOA-Definition==

A [http://en.wikipedia.org/wiki/Service_oriented_architecture Service Oriented Architecture] is an architecture that provides collection of services. These services need to inter-operate with each other to provide the functionality. This architecture requires a loose coupling with operating systems and other technologies that form the basis of the application. The loose coupling between services is required because each interaction has to be independent of the other. The communication between services could be either simple data being passed or it could be either an activity coordinated between distinct entities or services. Some means of interoperability is required to provide the services in larger terms. Instead of defining the API, the SOA implements the interfaces using the protocols and functionality. SOA separates functions into unique entities or services, which are accessed in a network by the users to combine and reuse them to develop the applications.

==Why SOA?==

Vast majority of Businesses working in the field of Information Technology have to justify their projects with a return on their investments. This puts Information Technology, as a field under enormous pressure. Information Technology must boast requirements that are increasingly responsive and flexible to the shifting needs of different Businesses.

Firms dealing with Information Technology must also be able to face the challenge of taking on an array of software systems that may or may not be compatible with one another. Moreover, Information Technology has to face demands to bring new commercial services to a much wider array of customers. Customers may access services through web interfaces, or may be part of a supply chain that needs to decrease the time and cost of manufacturing.

Thus, Information Technology companies are always on the look out for solutions that will help them meet the above demands – without having to spend a lot of money.SOA offers a solution to satisfy the above needs of the industry

==SOA-Benifits==
In architectural terms, a modern architectural design should be Service Oriented, loosely coupled, driven by events, able to support both integration and assembly, aligned with valuable life cycle support processes, and able to leverage existing infrastructure and applications.

When it comes to Service Oriented Architecture, it tends to offer a variety of different advantages over more traditional methods of distributing computing. These include offering business services across several platforms; providing location independence; providing authentication as well as authorization support on ever tier; a loosely coupled approach; and dynamic search and connectivity to other services. At the same time, it allows that services do not have to be located on a particular system or network.

=Design Patterns in SOA=
A design pattern is a general reusable solution to a commonly occurring problem in software design. A design pattern is not a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations.Design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved.

Design patterns play a major role in SOA. The implementation and deployment of SOA designs provide different challenges during product development life cycle.Such challenges made may SOA projects to be discontinued. Design patterns help in overcoming these problems by providing a solution to the problems posed.Each SOA design pattern provides a design solution in support of
successfully applying service orientation and establishing a quality
service-oriented architecture

=Design Patterns proposed =

The proposed Design Patterns for SOA fall in to following categories.They are listed below and corresponding patterns in
each category are given.

[http://www.soapatterns.org/masterlist_c.asp#ch6 Foundational Inventory Patterns]

These design patterns focus on providing solutions to the problems like maximizing re-composition and avoiding redundant logic .

examples for this category are Enterprise Inventory,Domain Inventory,Service Normalization,Logic Centralization, Service Layers Canonical Protocol,Canonical Schema

[http://www.soapatterns.org/masterlist_c.asp#ch7 Logical Inventory Layer Patterns]

These design patterns provide the solution to the problem of how can business logic be separated, reused, and governed independently?

examples for this category are Utility Abstraction,Entity Abstraction,Process Abstraction

[http://www.soapatterns.org/masterlist_c.asp#ch8 Inventory Centralization Patterns]

These patterns focus on providing solution for aspect of governing business logic etc

examples for this category are Process Centralization,Schema Centralization,Policy Centralization,Rules Centralization.

[http://www.soapatterns.org/masterlist_c.asp#ch9 Inventory Implementation Patterns]

These patterns help to solve implementation problems like limitations introduced by communication technology. Example like a single protocol may not accommodate all requirements etc

examples for this category are Dual Protocols,Canonical Resources,State Repository,Stateful Services,Service Grid,Inventory Endpoint,Cross-Domain Utility Layer

[http://www.soapatterns.org/masterlist_c.asp#ch10 Inventory Governance Patterns]

The patterns deal with the governance problems caused by service contract within the same service inventory

examples for this category are Canonical Expression,Metadata Centralization,Canonical Versioning

[http://www.soapatterns.org/masterlist_c.asp#ch11 Foundational Service Patterns]

The patterns proposed in this category focus on solving large business problems without having to build a stand alone solution.

examples for this category are Functional Decomposition,Service Encapsulation,Agnostic Context,Non-Agnostic Context,Agnostic Capability

[http://www.soapatterns.org/masterlist_c.asp#ch12 Service Implementation Patterns]

The patterns in this category focus on improving the realiability and availability of the service

examples for this category are Service Facade,Redundant Implementation,Service Data Replication,Partial State Deferral,Partial Validation,UI Mediator

[http://www.soapatterns.org/masterlist_c.asp#ch13 Service Security Patterns]

The patterns proposed in this category deal with the problem of data encapsulation and security aspects.

examples for this category are Exception Shielding,Message Screening,Trusted Subsystem ,Service Perimeter Guard

[http://www.soapatterns.org/masterlist_c.asp#ch14 Service Contract Design Patterns]

The patterns proposed in this category focus on providing solution for how to make the service contract suitable for all potential customers,make it aligned with other services etc

examples for this category are Decoupled Contract,Contract Centralization,Contract De normalization,Concurrent Contracts,Validation Abstraction

[http://www.soapatterns.org/masterlist_c.asp#ch15 Legacy Encapsulation Patterns]

The patterns proposed deals with the problems in legacy systems like processing of data contained in flat files, redundancy resulting in delivery to multiple channels etc

examples for this category are Legacy Wrapper, Multi-Channel Endpoint,File Gateway

[http://www.soapatterns.org/masterlist_c.asp#ch16 Service Governance Patterns]

These patterns provide solution for problems like updating the customers with changed service so that they are not affected, modifications in service etc

examples for this category are Compatible Change,Version Identification,Termination Notification,Service Refactoring,Service Decomposition,Proxy Capability,Decomposed Capability,Distributed Capability

[http://www.soapatterns.org/masterlist_c.asp#ch17 Capability Composition Patterns]

The pattern proposed focuses on the problem of How can a service capability solve a problem that requires logic outside of the service boundary and How can the same capability be used to help solve multiple problems?

examples for this category are Capability Composition,Capability Recomposition

[http://www.soapatterns.org/masterlist_c.asp#ch18 Service Messaging Patterns]

The patterns proposed in this category focus on setting up of message framework for transfer of data.

examples in this category are Service Messaging,Messaging Metadata,Service Agent,Intermediate Routing,State Messaging,Service Callback,Service Instance Routing,Asynchronous Queuing,Reliable Messaging,Event-Driven Messaging.

[http://www.soapatterns.org/masterlist_c.asp#ch19 Composition Implementation Patterns]

The patterns proposed in this category focus on problems during runtime like runtime activities that span multiple services fail, the parent business task is incomplete etc

examples for this category are Agnostic SubController,Composition Autonomy,Atomic Service Transaction,Compensating ServiceTransaction

[http://www.soapatterns.org/masterlist_c.asp#ch20 Service Interaction Security Patterns]

The proposed patterns in this category are focused on security methods like encryption,decryption,authenticating the data,consumer and service

examples for this category are Data Confidentiality, Data Origin Authentication, Direct Authentication, Brokered Authentication

[http://www.soapatterns.org/masterlist_c.asp#ch21 Transformation Patterns]

The Patterns proposed in this category concrete on how data from one data model can be dynamically converted to comply to a different data model.

examples for this category are Data Model Transformation,Data Format Transformation, Protocol Bridging

[http://www.soapatterns.org/masterlist_c.asp#ch22 Common Compound Design Patterns]

A compound pattern is a coarse-grained pattern comprised of a set of finer-grained patterns.

examples for this category are Orchestration,Enterprise Service Bus,Service Broker,Canonical Schema Bus,Official Endpoint,Federated Endpoint Layer,Three-Layer Inventory

=Example Design Patterns =

The following section describes five design patterns which are utilized in SOA.The described patterns provide the problem and corresponding solution

==Canonical protocol==

[[Image:Canonicalpattern.jpg.png]]

Problem: Services that support different communication technologies compromise interoperability, limit the quantity of potential consumers, and introduce the need for undesirable protocol bridging measures.

Solution: The architecture establishes a single communications technology as the sole or primary medium by which services can interact.

From the above figure it is observed that though still delivered by different projects via different vendor platforms A,B,C etc these services conform to one centralized communications technology, making them technologically compatible.

==Dual protocol==

[[Image:dualprotocol.png]]

Problem: Canonical Protocol requires that all services conform to the use of the same communications technology; however, a single protocol may not be able to accommodate all service requirements, thereby introducing limitations.

Solution: The service inventory architecture is designed to support services based on primary and secondary protocols.

Regardless of protocol, all services must invoke each other via their official service contracts (A, B). Bypassing the contract may seem convenient when the underlying service logic of the primary service supports the same protocol as the secondary service (C), but it is an anti-pattern that will eventually inhibit the application of this pattern and further weaken the overall service inventory foundation.

==Protocol Bridging==

[[Image:protocolbridging.png]]

Problem: Services using different communication protocols or different versions of the same protocol cannot exchange data.

Solution: Bridging logic is introduced to enable communication between different communication protocols by dynamically converting one protocol to another at runtime.

From the above figure it can be noticed that the consumer programs interact with a middle-tier broker that provides protocol bridging features. Separate protocol adapters are used to translate the two incompatible protocols to the required SOAP version 1.2 over HTTP. The broker then transmits the messages to the service on behalf of the consumers.

==UI Mediator==

[[Image:uimediator.png]]

Problem: Because the behavior of individual services can vary depending on their design,runtime usage, and the workload required to carry out a given capability, the consistency with which a service-oriented solution can respond to requests originating from a user-interface can fluctuate, leading to a poor user experience.

Solution: Establish mediator logic solely responsible for ensuring timely interaction and feedback with user-interfaces and presentation logic.

The mediator service (D) regularly updates the user interface while services A, B, and C work behind-the-scenes to complete the task

==Service Facade==

[[Image:service_facade.png]]

Problem: The coupling of the core service logic to contracts and implementation resources can inhibit its evolution and negatively impact service consumers.

Solution: A service facade component is used to abstract a part of the service architecture with negative coupling potential.

Facade logic is placed in between the contract and the core service logic. This allows the core service logic to remain decoupled from the contract.

=Similarities and Differences Between Patterns for SOA and Traditional pattens proposed by GoF=

The Gang of Four(Gof) comprising of Eric Gamma, Richard Helm, Ralph Johnson, and John Vlissides have documented the design patterns that were followed by Software developers and architects in object oriented space. They have documented 23 design patterns which are collectively called as Traditional design patterns.

The design patterns in SOA are similiar in some aspects to the traditional patterns.They also differ from the traditional patterns. The similiarities and differences between them are provided in this section

==Differences==

The differences between the SOA design patterns and traditional design patterns have been come up based on the individual functionality that each pattern provide. Following are the differences,

1) The composite pattern organizes the objects in the manner to represent the part-whole hierarchies in a traditional two-tier hierarchy.

The [http://www.soapatterns.org/agnostic_subcontroller.asp agnostic sub-controller] implements the service composability but it differs from the composite pattern in such a way that cross-entity functionality is abstracted and made accessible through the sub –controller capability.

For instance, the traditional composite pattern has the object representing a part-whole hierarchy as in the below figure of graphic class which has draw(). If we require a cross-entity functionality as in the below figure, we require a colored rectangle, we require the functionality fill() of color class. Hence the sub-controller module is created which has the functionality of different parents, thus making it reusable.

figure to illustrate above difference

[[Image:Composite_example.png]]

2)
The traditional bridge pattern separates the abstraction from its implementation in order to vary independently. Whereas the canonical protocol avoids the protocol bridging in such a way that there is a single communication technology through which the services can interact.
In the below figure of bridge pattern, the relationship between the abstraction and implementor is bridge and it results the implementor to vary independently from the abstraction by having different ConcreteImplementor. The canonical protocol avoids the variation by having a single communication technology between different objects.

figure for above difference

[[Image:Traditional_bridge.png]]
Figure for Traditional bridge pattern

For canonical protocol refer to the explanation given in example design patterns

3) The traditional builder pattern decouples the construction of the object from its representation so that the same construction process can be used to develop different representations. The different representations (contracts) are addressed in SOA by the Concurrent Contracts with the application of Service-façade design pattern. With service-façade design pattern, an abstraction is created to support the interaction between different contracts. As a result, different contracts can be created for a single service.
In the below figure, the conversion of the text document is separated from the reader of RTF document, so that the text document can be represented in different forms like ASCIIText, TeXText and TextWidget. The different representation is achieved by decoupling of construction and abstraction. In the case of concurrent contracts pattern, the different contracts or services (invoices) are created for different consumer through service-façade by creating a new abstraction.

[[Image:Builder.png]]
Figure for Traditional Builder pattern

[[Image:Concurrent_pattern.png]]
Figure for Concurrent pattern

==Similarities==
1) The Service-façade design pattern is similar to the façade (traditional) pattern in the manner that it implements the façade logic which is creating an abstraction for intra-communication within objects to the service architecture. The advantage by adding the façade logic to the service architecture is that it preserves the underlying logic from run-time changes.

2) The UI Mediator design pattern implements the mediator logic of traditional mediator pattern. The mediator logic aims to provide the user responses in a way that user understands, independently of what the underlying services perform.

3) The Intermediate routing pattern in SOA is similar to Decorator pattern (traditional) in the functionality that it adds the required logic at run-time. The decorator adds the additional functionality to the object at run-time. The intermediate routing pattern is about placing the routing logic to address the run-time scenarios.

4)The Capability Composition pattern in SOA implements the Composite pattern (traditional). The Capability Composition is about composing one or more capabilities outside the service’s context to address the large, complex problem.

5) The Decoupled Contract pattern implements the traditional Bridge pattern in the manner that service contract is separated from the implementation. The Bridge pattern decouples the abstraction from implementation to facilitate the variation of both (abstraction and implementation).

6) The Legacy Wrapper pattern is related to traditional Adapter pattern. The Legacy Wrapper pattern protects the legacy logic by providing a standard service that takes of protecting the legacy details by encapsulating, extraction or elimination. The encapsulation, extraction or elimination is done in order to change the service as the consumer requires it. This is related to adapter in a way that it converts the interface of one class to another as the client expects.

=Summary=

=Glossary=

1.Serive : "A service is a discoverable resource that executes a repeatable task, and is described by an externalized service specification."

2.[http://www.ibm.com/developerworks/webservices/library/ws-soa-term1/ SOA Terminology]

3.SOA :[http://en.wikipedia.org/wiki/Service-oriented_architecture Service oriented Architecture]

4.API :[http://en.wikipedia.org/wiki/Application_programming_interface Application programming interface]

5.SOAP :[http://en.wikipedia.org/wiki/SOAP Simple Object Access Protocol]

6.HTTP :[http://en.wikipedia.org/wiki/HyperText_Transfer_Protocol Hypertext Transfer Protocol]

7.GoF :[http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Gang of Four]

8.[http://soaglossary.com/ SOA Glossory]

=References=

1.[http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Design patterns for object oriented software]

2.[http://en.wikipedia.org/wiki/Service-oriented_architecture#Introduction Service Oriented Architecture]

3.[http://www.exforsys.com/tutorials/soa/soa-definitions-and-certification.html SOA Tutorial]

4.[http://www.soapatterns.org/ soa design patterns]

5.[http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29 design pattern]

6.[http://www.oracle.com/technologies/soa/center.html oracle SOA centre]

7.[http://www.ibm.com/developerworks/webservices/library/ws-soa-term1/ IBMs SOA Contributions]

8.[http://www.oracle.com/technology/pub/articles/erl_soa_design_patterns_app_sequences.html SOA Design patterns application sequences by oracle]

CSC/ECE 517 Fall 2009/wiki2 16 rs

2009-10-10T02:22:07Z

Screenit: /* SOA-Definition */

CSC/ECE 517 Fall 2009/wiki2 16 rs

SOA provides another view of providing functionality based upon services offered in terms of protocols and a specific API. Research and report on what patterns have been proposed and are utilized within this domain. How do they differ from traditional design patterns proposed by Eric Gamma, Richard Helm, Ralph Johnson, and John Vlissides? How are they similar?

----
=Introduction=

This article focuses on the design patterns which are proposed and utilized in the [http://en.wikipedia.org/wiki/Service_oriented_architecture Service Oriented Architecture]. As the SOA provides its services through the protocols and API, this article throws light on the design patterns that specifically provide services through protocols like [http://www.soapatterns.org/canonical_protocol.asp Canonical protocol], [http://www.soapatterns.org/dual_protocols.asp Dual protocols] and [http://www.soapatterns.org/protocol_bridging.asp Protocol Bridging]. In a broader perspective, other design patterns have been explained tersely. In addition to explanation of the SOA design patterns, this compares the SOA design patterns with the traditional design patterns proposed by the ‘Gang of Four’ (Eric Gamma, Richard Helm, Ralph Johnson, and John Vlissides) and comes up with the differences and similarities between them.

=Service Oriented Architecture-An Overview=

==SOA-Definition==

A [http://en.wikipedia.org/wiki/Service_oriented_architecture Service Oriented Architecture] is an architecture that provides collection of services. These services need to inter-operate with each other to provide the functionality. This architecture requires a loose coupling with operating systems and other technologies that form the basis of the application. The loose coupling between services is required because each interaction has to be independent of the other. The communication between services could be either simple data being passed or it could be either an activity coordinated between distinct entities or services.
The services communicate with each other to provide a large.The communication can involve either simple data passing or it could involve two or more services coordinating some activity. Some means of connecting services to each other is needed.Rather than defining an API, SOA defines the interface in terms of protocols and functionality. An endpoint is the entry point to such an SOA implementation.Service-orientation requires loose coupling of services with operating systems, and other technologies that underlie applications. SOA separates functions into distinct units, or services, which developers make accessible over a network in order to allow users to combine and reuse them in the production of applications. These services communicate with each other by passing data from one service to another, or by coordinating an activity between two or more services.

==Why SOA?==

Vast majority of Businesses working in the field of Information Technology have to justify their projects with a return on their investments. This puts Information Technology, as a field under enormous pressure. Information Technology must boast requirements that are increasingly responsive and flexible to the shifting needs of different Businesses.

Firms dealing with Information Technology must also be able to face the challenge of taking on an array of software systems that may or may not be compatible with one another. Moreover, Information Technology has to face demands to bring new commercial services to a much wider array of customers. Customers may access services through web interfaces, or may be part of a supply chain that needs to decrease the time and cost of manufacturing.

Thus, Information Technology companies are always on the look out for solutions that will help them meet the above demands – without having to spend a lot of money.SOA offers a solution to satisfy the above needs of the industry

==SOA-Benifits==
In architectural terms, a modern architectural design should be Service Oriented, loosely coupled, driven by events, able to support both integration and assembly, aligned with valuable life cycle support processes, and able to leverage existing infrastructure and applications.

When it comes to Service Oriented Architecture, it tends to offer a variety of different advantages over more traditional methods of distributing computing. These include offering business services across several platforms; providing location independence; providing authentication as well as authorization support on ever tier; a loosely coupled approach; and dynamic search and connectivity to other services. At the same time, it allows that services do not have to be located on a particular system or network.

=Design Patterns in SOA=
A design pattern is a general reusable solution to a commonly occurring problem in software design. A design pattern is not a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations.Design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved.

Design patterns play a major role in SOA. The implementation and deployment of SOA designs provide different challenges during product development life cycle.Such challenges made may SOA projects to be discontinued. Design patterns help in overcoming these problems by providing a solution to the problems posed.Each SOA design pattern provides a design solution in support of
successfully applying service orientation and establishing a quality
service-oriented architecture

=Design Patterns proposed =

The proposed Design Patterns for SOA fall in to following categories.They are listed below and corresponding patterns in
each category are given.

[http://www.soapatterns.org/masterlist_c.asp#ch6 Foundational Inventory Patterns]

These design patterns focus on providing solutions to the problems like maximizing re-composition and avoiding redundant logic .

examples for this category are Enterprise Inventory,Domain Inventory,Service Normalization,Logic Centralization, Service Layers Canonical Protocol,Canonical Schema

[http://www.soapatterns.org/masterlist_c.asp#ch7 Logical Inventory Layer Patterns]

These design patterns provide the solution to the problem of how can business logic be separated, reused, and governed independently?

examples for this category are Utility Abstraction,Entity Abstraction,Process Abstraction

[http://www.soapatterns.org/masterlist_c.asp#ch8 Inventory Centralization Patterns]

These patterns focus on providing solution for aspect of governing business logic etc

examples for this category are Process Centralization,Schema Centralization,Policy Centralization,Rules Centralization.

[http://www.soapatterns.org/masterlist_c.asp#ch9 Inventory Implementation Patterns]

These patterns help to solve implementation problems like limitations introduced by communication technology. Example like a single protocol may not accommodate all requirements etc

examples for this category are Dual Protocols,Canonical Resources,State Repository,Stateful Services,Service Grid,Inventory Endpoint,Cross-Domain Utility Layer

[http://www.soapatterns.org/masterlist_c.asp#ch10 Inventory Governance Patterns]

The patterns deal with the governance problems caused by service contract within the same service inventory

examples for this category are Canonical Expression,Metadata Centralization,Canonical Versioning

[http://www.soapatterns.org/masterlist_c.asp#ch11 Foundational Service Patterns]

The patterns proposed in this category focus on solving large business problems without having to build a stand alone solution.

examples for this category are Functional Decomposition,Service Encapsulation,Agnostic Context,Non-Agnostic Context,Agnostic Capability

[http://www.soapatterns.org/masterlist_c.asp#ch12 Service Implementation Patterns]

The patterns in this category focus on improving the realiability and availability of the service

examples for this category are Service Facade,Redundant Implementation,Service Data Replication,Partial State Deferral,Partial Validation,UI Mediator

[http://www.soapatterns.org/masterlist_c.asp#ch13 Service Security Patterns]

The patterns proposed in this category deal with the problem of data encapsulation and security aspects.

examples for this category are Exception Shielding,Message Screening,Trusted Subsystem ,Service Perimeter Guard

[http://www.soapatterns.org/masterlist_c.asp#ch14 Service Contract Design Patterns]

The patterns proposed in this category focus on providing solution for how to make the service contract suitable for all potential customers,make it aligned with other services etc

examples for this category are Decoupled Contract,Contract Centralization,Contract De normalization,Concurrent Contracts,Validation Abstraction

[http://www.soapatterns.org/masterlist_c.asp#ch15 Legacy Encapsulation Patterns]

The patterns proposed deals with the problems in legacy systems like processing of data contained in flat files, redundancy resulting in delivery to multiple channels etc

examples for this category are Legacy Wrapper, Multi-Channel Endpoint,File Gateway

[http://www.soapatterns.org/masterlist_c.asp#ch16 Service Governance Patterns]

These patterns provide solution for problems like updating the customers with changed service so that they are not affected, modifications in service etc

examples for this category are Compatible Change,Version Identification,Termination Notification,Service Refactoring,Service Decomposition,Proxy Capability,Decomposed Capability,Distributed Capability

[http://www.soapatterns.org/masterlist_c.asp#ch17 Capability Composition Patterns]

The pattern proposed focuses on the problem of How can a service capability solve a problem that requires logic outside of the service boundary and How can the same capability be used to help solve multiple problems?

examples for this category are Capability Composition,Capability Recomposition

[http://www.soapatterns.org/masterlist_c.asp#ch18 Service Messaging Patterns]

The patterns proposed in this category focus on setting up of message framework for transfer of data.

examples in this category are Service Messaging,Messaging Metadata,Service Agent,Intermediate Routing,State Messaging,Service Callback,Service Instance Routing,Asynchronous Queuing,Reliable Messaging,Event-Driven Messaging.

[http://www.soapatterns.org/masterlist_c.asp#ch19 Composition Implementation Patterns]

The patterns proposed in this category focus on problems during runtime like runtime activities that span multiple services fail, the parent business task is incomplete etc

examples for this category are Agnostic SubController,Composition Autonomy,Atomic Service Transaction,Compensating ServiceTransaction

[http://www.soapatterns.org/masterlist_c.asp#ch20 Service Interaction Security Patterns]

The proposed patterns in this category are focused on security methods like encryption,decryption,authenticating the data,consumer and service

examples for this category are Data Confidentiality, Data Origin Authentication, Direct Authentication, Brokered Authentication

[http://www.soapatterns.org/masterlist_c.asp#ch21 Transformation Patterns]

The Patterns proposed in this category concrete on how data from one data model can be dynamically converted to comply to a different data model.

examples for this category are Data Model Transformation,Data Format Transformation, Protocol Bridging

[http://www.soapatterns.org/masterlist_c.asp#ch22 Common Compound Design Patterns]

A compound pattern is a coarse-grained pattern comprised of a set of finer-grained patterns.

examples for this category are Orchestration,Enterprise Service Bus,Service Broker,Canonical Schema Bus,Official Endpoint,Federated Endpoint Layer,Three-Layer Inventory

=Example Design Patterns =

The following section describes five design patterns which are utilized in SOA.The described patterns provide the problem and corresponding solution

==Canonical protocol==

[[Image:Canonicalpattern.jpg.png]]

Problem: Services that support different communication technologies compromise interoperability, limit the quantity of potential consumers, and introduce the need for undesirable protocol bridging measures.

Solution: The architecture establishes a single communications technology as the sole or primary medium by which services can interact.

From the above figure it is observed that though still delivered by different projects via different vendor platforms A,B,C etc these services conform to one centralized communications technology, making them technologically compatible.

==Dual protocol==

[[Image:dualprotocol.png]]

Problem: Canonical Protocol requires that all services conform to the use of the same communications technology; however, a single protocol may not be able to accommodate all service requirements, thereby introducing limitations.

Solution: The service inventory architecture is designed to support services based on primary and secondary protocols.

Regardless of protocol, all services must invoke each other via their official service contracts (A, B). Bypassing the contract may seem convenient when the underlying service logic of the primary service supports the same protocol as the secondary service (C), but it is an anti-pattern that will eventually inhibit the application of this pattern and further weaken the overall service inventory foundation.

==Protocol Bridging==

[[Image:protocolbridging.png]]

Problem: Services using different communication protocols or different versions of the same protocol cannot exchange data.

Solution: Bridging logic is introduced to enable communication between different communication protocols by dynamically converting one protocol to another at runtime.

From the above figure it can be noticed that the consumer programs interact with a middle-tier broker that provides protocol bridging features. Separate protocol adapters are used to translate the two incompatible protocols to the required SOAP version 1.2 over HTTP. The broker then transmits the messages to the service on behalf of the consumers.

==UI Mediator==

[[Image:uimediator.png]]

Problem: Because the behavior of individual services can vary depending on their design,runtime usage, and the workload required to carry out a given capability, the consistency with which a service-oriented solution can respond to requests originating from a user-interface can fluctuate, leading to a poor user experience.

Solution: Establish mediator logic solely responsible for ensuring timely interaction and feedback with user-interfaces and presentation logic.

The mediator service (D) regularly updates the user interface while services A, B, and C work behind-the-scenes to complete the task

==Service Facade==

[[Image:service_facade.png]]

Problem: The coupling of the core service logic to contracts and implementation resources can inhibit its evolution and negatively impact service consumers.

Solution: A service facade component is used to abstract a part of the service architecture with negative coupling potential.

Facade logic is placed in between the contract and the core service logic. This allows the core service logic to remain decoupled from the contract.

=Similarities and Differences Between Patterns for SOA and Traditional pattens proposed by GoF=

The Gang of Four(Gof) comprising of Eric Gamma, Richard Helm, Ralph Johnson, and John Vlissides have documented the design patterns that were followed by Software developers and architects in object oriented space. They have documented 23 design patterns which are collectively called as Traditional design patterns.

The design patterns in SOA are similiar in some aspects to the traditional patterns.They also differ from the traditional patterns. The similiarities and differences between them are provided in this section

==Differences==

The differences between the SOA design patterns and traditional design patterns have been come up based on the individual functionality that each pattern provide. Following are the differences,

1) The composite pattern organizes the objects in the manner to represent the part-whole hierarchies in a traditional two-tier hierarchy.

The [http://www.soapatterns.org/agnostic_subcontroller.asp agnostic sub-controller] implements the service composability but it differs from the composite pattern in such a way that cross-entity functionality is abstracted and made accessible through the sub –controller capability.

For instance, the traditional composite pattern has the object representing a part-whole hierarchy as in the below figure of graphic class which has draw(). If we require a cross-entity functionality as in the below figure, we require a colored rectangle, we require the functionality fill() of color class. Hence the sub-controller module is created which has the functionality of different parents, thus making it reusable.

figure to illustrate above difference

[[Image:Composite_example.png]]

2)
The traditional bridge pattern separates the abstraction from its implementation in order to vary independently. Whereas the canonical protocol avoids the protocol bridging in such a way that there is a single communication technology through which the services can interact.
In the below figure of bridge pattern, the relationship between the abstraction and implementor is bridge and it results the implementor to vary independently from the abstraction by having different ConcreteImplementor. The canonical protocol avoids the variation by having a single communication technology between different objects.

figure for above difference

[[Image:Traditional_bridge.png]]
Figure for Traditional bridge pattern

For canonical protocol refer to the explanation given in example design patterns

3) The traditional builder pattern decouples the construction of the object from its representation so that the same construction process can be used to develop different representations. The different representations (contracts) are addressed in SOA by the Concurrent Contracts with the application of Service-façade design pattern. With service-façade design pattern, an abstraction is created to support the interaction between different contracts. As a result, different contracts can be created for a single service.
In the below figure, the conversion of the text document is separated from the reader of RTF document, so that the text document can be represented in different forms like ASCIIText, TeXText and TextWidget. The different representation is achieved by decoupling of construction and abstraction. In the case of concurrent contracts pattern, the different contracts or services (invoices) are created for different consumer through service-façade by creating a new abstraction.

[[Image:Builder.png]]
Figure for Traditional Builder pattern

[[Image:Concurrent_pattern.png]]
Figure for Concurrent pattern

==Similarities==
1) The Service-façade design pattern is similar to the façade (traditional) pattern in the manner that it implements the façade logic which is creating an abstraction for intra-communication within objects to the service architecture. The advantage by adding the façade logic to the service architecture is that it preserves the underlying logic from run-time changes.

2) The UI Mediator design pattern implements the mediator logic of traditional mediator pattern. The mediator logic aims to provide the user responses in a way that user understands, independently of what the underlying services perform.

3) The Intermediate routing pattern in SOA is similar to Decorator pattern (traditional) in the functionality that it adds the required logic at run-time. The decorator adds the additional functionality to the object at run-time. The intermediate routing pattern is about placing the routing logic to address the run-time scenarios.

4)The Capability Composition pattern in SOA implements the Composite pattern (traditional). The Capability Composition is about composing one or more capabilities outside the service’s context to address the large, complex problem.

5) The Decoupled Contract pattern implements the traditional Bridge pattern in the manner that service contract is separated from the implementation. The Bridge pattern decouples the abstraction from implementation to facilitate the variation of both (abstraction and implementation).

6) The Legacy Wrapper pattern is related to traditional Adapter pattern. The Legacy Wrapper pattern protects the legacy logic by providing a standard service that takes of protecting the legacy details by encapsulating, extraction or elimination. The encapsulation, extraction or elimination is done in order to change the service as the consumer requires it. This is related to adapter in a way that it converts the interface of one class to another as the client expects.

=Summary=

=Glossary=

1.Serive : "A service is a discoverable resource that executes a repeatable task, and is described by an externalized service specification."

2.[http://www.ibm.com/developerworks/webservices/library/ws-soa-term1/ SOA Terminology]

3.SOA :[http://en.wikipedia.org/wiki/Service-oriented_architecture Service oriented Architecture]

4.API :[http://en.wikipedia.org/wiki/Application_programming_interface Application programming interface]

5.SOAP :[http://en.wikipedia.org/wiki/SOAP Simple Object Access Protocol]

6.HTTP :[http://en.wikipedia.org/wiki/HyperText_Transfer_Protocol Hypertext Transfer Protocol]

7.GoF :[http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Gang of Four]

8.[http://soaglossary.com/ SOA Glossory]

=References=

1.[http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Design patterns for object oriented software]

2.[http://en.wikipedia.org/wiki/Service-oriented_architecture#Introduction Service Oriented Architecture]

3.[http://www.exforsys.com/tutorials/soa/soa-definitions-and-certification.html SOA Tutorial]

4.[http://www.soapatterns.org/ soa design patterns]

5.[http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29 design pattern]

6.[http://www.oracle.com/technologies/soa/center.html oracle SOA centre]

7.[http://www.ibm.com/developerworks/webservices/library/ws-soa-term1/ IBMs SOA Contributions]

8.[http://www.oracle.com/technology/pub/articles/erl_soa_design_patterns_app_sequences.html SOA Design patterns application sequences by oracle]

CSC/ECE 517 Fall 2009/wiki2 16 rs

2009-10-10T01:45:39Z

Screenit: /* Introduction */

CSC/ECE 517 Fall 2009/wiki2 16 rs

SOA provides another view of providing functionality based upon services offered in terms of protocols and a specific API. Research and report on what patterns have been proposed and are utilized within this domain. How do they differ from traditional design patterns proposed by Eric Gamma, Richard Helm, Ralph Johnson, and John Vlissides? How are they similar?

----
=Introduction=

This article focuses on the design patterns which are proposed and utilized in the [http://en.wikipedia.org/wiki/Service_oriented_architecture Service Oriented Architecture]. As the SOA provides its services through the protocols and API, this article throws light on the design patterns that specifically provide services through protocols like [http://www.soapatterns.org/canonical_protocol.asp Canonical protocol], [http://www.soapatterns.org/dual_protocols.asp Dual protocols] and [http://www.soapatterns.org/protocol_bridging.asp Protocol Bridging]. In a broader perspective, other design patterns have been explained tersely. In addition to explanation of the SOA design patterns, this compares the SOA design patterns with the traditional design patterns proposed by the ‘Gang of Four’ (Eric Gamma, Richard Helm, Ralph Johnson, and John Vlissides) and comes up with the differences and similarities between them.

=Service Oriented Architecture-An Overview=

==SOA-Definition==

A service-oriented architecture is essentially a collection of services. These services communicate with each other.The communication can involve either simple data passing or it could involve two or more services coordinating some activity. Some means of connecting services to each other is needed.Rather than defining an API, SOA defines the interface in terms of protocols and functionality. An endpoint is the entry point to such an SOA implementation.Service-orientation requires loose coupling of services with operating systems, and other technologies that underlie applications. SOA separates functions into distinct units, or services, which developers make accessible over a network in order to allow users to combine and reuse them in the production of applications. These services communicate with each other by passing data from one service to another, or by coordinating an activity between two or more services.

==Why SOA?==

Vast majority of Businesses working in the field of Information Technology have to justify their projects with a return on their investments. This puts Information Technology, as a field under enormous pressure. Information Technology must boast requirements that are increasingly responsive and flexible to the shifting needs of different Businesses.

Firms dealing with Information Technology must also be able to face the challenge of taking on an array of software systems that may or may not be compatible with one another. Moreover, Information Technology has to face demands to bring new commercial services to a much wider array of customers. Customers may access services through web interfaces, or may be part of a supply chain that needs to decrease the time and cost of manufacturing.

Thus, Information Technology companies are always on the look out for solutions that will help them meet the above demands – without having to spend a lot of money.SOA offers a solution to satisfy the above needs of the industry

==SOA-Benifits==
In architectural terms, a modern architectural design should be Service Oriented, loosely coupled, driven by events, able to support both integration and assembly, aligned with valuable life cycle support processes, and able to leverage existing infrastructure and applications.

When it comes to Service Oriented Architecture, it tends to offer a variety of different advantages over more traditional methods of distributing computing. These include offering business services across several platforms; providing location independence; providing authentication as well as authorization support on ever tier; a loosely coupled approach; and dynamic search and connectivity to other services. At the same time, it allows that services do not have to be located on a particular system or network.

=Design Patterns in SOA=
A design pattern is a general reusable solution to a commonly occurring problem in software design. A design pattern is not a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations.Design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved.

Design patterns play a major role in SOA. The implementation and deployment of SOA designs provide different challenges during product development life cycle.Such challenges made may SOA projects to be discontinued. Design patterns help in overcoming these problems by providing a solution to the problems posed.Each SOA design pattern provides a design solution in support of
successfully applying service orientation and establishing a quality
service-oriented architecture

=Design Patterns proposed =

The proposed Design Patterns for SOA fall in to following categories.They are listed below and corresponding patterns in
each category are given.

[http://www.soapatterns.org/masterlist_c.asp#ch6 Foundational Inventory Patterns]

These design patterns focus on providing solutions to the problems like maximizing re-composition and avoiding redundant logic .

examples for this category are Enterprise Inventory,Domain Inventory,Service Normalization,Logic Centralization, Service Layers Canonical Protocol,Canonical Schema

[http://www.soapatterns.org/masterlist_c.asp#ch7 Logical Inventory Layer Patterns]

These design patterns provide the solution to the problem of how can business logic be separated, reused, and governed independently?

examples for this category are Utility Abstraction,Entity Abstraction,Process Abstraction

[http://www.soapatterns.org/masterlist_c.asp#ch8 Inventory Centralization Patterns]

These patterns focus on providing solution for aspect of governing business logic etc

examples for this category are Process Centralization,Schema Centralization,Policy Centralization,Rules Centralization.

[http://www.soapatterns.org/masterlist_c.asp#ch9 Inventory Implementation Patterns]

These patterns help to solve implementation problems like limitations introduced by communication technology. Example like a single protocol may not accommodate all requirements etc

examples for this category are Dual Protocols,Canonical Resources,State Repository,Stateful Services,Service Grid,Inventory Endpoint,Cross-Domain Utility Layer

[http://www.soapatterns.org/masterlist_c.asp#ch10 Inventory Governance Patterns]

The patterns deal with the governance problems caused by service contract within the same service inventory

examples for this category are Canonical Expression,Metadata Centralization,Canonical Versioning

[http://www.soapatterns.org/masterlist_c.asp#ch11 Foundational Service Patterns]

The patterns proposed in this category focus on solving large business problems without having to build a stand alone solution.

examples for this category are Functional Decomposition,Service Encapsulation,Agnostic Context,Non-Agnostic Context,Agnostic Capability

[http://www.soapatterns.org/masterlist_c.asp#ch12 Service Implementation Patterns]

The patterns in this category focus on improving the realiability and availability of the service

examples for this category are Service Facade,Redundant Implementation,Service Data Replication,Partial State Deferral,Partial Validation,UI Mediator

[http://www.soapatterns.org/masterlist_c.asp#ch13 Service Security Patterns]

The patterns proposed in this category deal with the problem of data encapsulation and security aspects.

examples for this category are Exception Shielding,Message Screening,Trusted Subsystem ,Service Perimeter Guard

[http://www.soapatterns.org/masterlist_c.asp#ch14 Service Contract Design Patterns]

The patterns proposed in this category focus on providing solution for how to make the service contract suitable for all potential customers,make it aligned with other services etc

examples for this category are Decoupled Contract,Contract Centralization,Contract De normalization,Concurrent Contracts,Validation Abstraction

[http://www.soapatterns.org/masterlist_c.asp#ch15 Legacy Encapsulation Patterns]

The patterns proposed deals with the problems in legacy systems like processing of data contained in flat files, redundancy resulting in delivery to multiple channels etc

examples for this category are Legacy Wrapper, Multi-Channel Endpoint,File Gateway

[http://www.soapatterns.org/masterlist_c.asp#ch16 Service Governance Patterns]

These patterns provide solution for problems like updating the customers with changed service so that they are not affected, modifications in service etc

examples for this category are Compatible Change,Version Identification,Termination Notification,Service Refactoring,Service Decomposition,Proxy Capability,Decomposed Capability,Distributed Capability

[http://www.soapatterns.org/masterlist_c.asp#ch17 Capability Composition Patterns]

The pattern proposed focuses on the problem of How can a service capability solve a problem that requires logic outside of the service boundary and How can the same capability be used to help solve multiple problems?

examples for this category are Capability Composition,Capability Recomposition

[http://www.soapatterns.org/masterlist_c.asp#ch18 Service Messaging Patterns]

The patterns proposed in this category focus on setting up of message framework for transfer of data.

examples in this category are Service Messaging,Messaging Metadata,Service Agent,Intermediate Routing,State Messaging,Service Callback,Service Instance Routing,Asynchronous Queuing,Reliable Messaging,Event-Driven Messaging.

[http://www.soapatterns.org/masterlist_c.asp#ch19 Composition Implementation Patterns]

The patterns proposed in this category focus on problems during runtime like runtime activities that span multiple services fail, the parent business task is incomplete etc

examples for this category are Agnostic SubController,Composition Autonomy,Atomic Service Transaction,Compensating ServiceTransaction

[http://www.soapatterns.org/masterlist_c.asp#ch20 Service Interaction Security Patterns]

The proposed patterns in this category are focused on security methods like encryption,decryption,authenticating the data,consumer and service

examples for this category are Data Confidentiality, Data Origin Authentication, Direct Authentication, Brokered Authentication

[http://www.soapatterns.org/masterlist_c.asp#ch21 Transformation Patterns]

The Patterns proposed in this category concrete on how data from one data model can be dynamically converted to comply to a different data model.

examples for this category are Data Model Transformation,Data Format Transformation, Protocol Bridging

[http://www.soapatterns.org/masterlist_c.asp#ch22 Common Compound Design Patterns]

A compound pattern is a coarse-grained pattern comprised of a set of finer-grained patterns.

examples for this category are Orchestration,Enterprise Service Bus,Service Broker,Canonical Schema Bus,Official Endpoint,Federated Endpoint Layer,Three-Layer Inventory

=Example Design Patterns =

The following section describes five design patterns which are utilized in SOA.The described patterns provide the problem and corresponding solution

==Canonical protocol==

[[Image:Canonicalpattern.jpg.png]]

Problem: Services that support different communication technologies compromise interoperability, limit the quantity of potential consumers, and introduce the need for undesirable protocol bridging measures.

Solution: The architecture establishes a single communications technology as the sole or primary medium by which services can interact.

From the above figure it is observed that though still delivered by different projects via different vendor platforms A,B,C etc these services conform to one centralized communications technology, making them technologically compatible.

==Dual protocol==

[[Image:dualprotocol.png]]

Problem: Canonical Protocol requires that all services conform to the use of the same communications technology; however, a single protocol may not be able to accommodate all service requirements, thereby introducing limitations.

Solution: The service inventory architecture is designed to support services based on primary and secondary protocols.

Regardless of protocol, all services must invoke each other via their official service contracts (A, B). Bypassing the contract may seem convenient when the underlying service logic of the primary service supports the same protocol as the secondary service (C), but it is an anti-pattern that will eventually inhibit the application of this pattern and further weaken the overall service inventory foundation.

==Protocol Bridging==

[[Image:protocolbridging.png]]

Problem: Services using different communication protocols or different versions of the same protocol cannot exchange data.

Solution: Bridging logic is introduced to enable communication between different communication protocols by dynamically converting one protocol to another at runtime.

From the above figure it can be noticed that the consumer programs interact with a middle-tier broker that provides protocol bridging features. Separate protocol adapters are used to translate the two incompatible protocols to the required SOAP version 1.2 over HTTP. The broker then transmits the messages to the service on behalf of the consumers.

==UI Mediator==

[[Image:uimediator.png]]

Problem: Because the behavior of individual services can vary depending on their design,runtime usage, and the workload required to carry out a given capability, the consistency with which a service-oriented solution can respond to requests originating from a user-interface can fluctuate, leading to a poor user experience.

Solution: Establish mediator logic solely responsible for ensuring timely interaction and feedback with user-interfaces and presentation logic.

The mediator service (D) regularly updates the user interface while services A, B, and C work behind-the-scenes to complete the task

==Service Facade==

[[Image:service_facade.png]]

Problem: The coupling of the core service logic to contracts and implementation resources can inhibit its evolution and negatively impact service consumers.

Solution: A service facade component is used to abstract a part of the service architecture with negative coupling potential.

Facade logic is placed in between the contract and the core service logic. This allows the core service logic to remain decoupled from the contract.

=Similarities and Differences Between Patterns for SOA and Traditional pattens proposed by GoF=

The Gang of Four(Gof) comprising of Eric Gamma, Richard Helm, Ralph Johnson, and John Vlissides have documented the design patterns that were followed by Software developers and architects in object oriented space. They have documented 23 design patterns which are collectively called as Traditional design patterns.

The design patterns in SOA are similiar in some aspects to the traditional patterns.They also differ from the traditional patterns. The similiarities and differences between them are provided in this section

==Differences==

The differences between the SOA design patterns and traditional design patterns have been come up based on the individual functionality that each pattern provide. Following are the differences,

1) The composite pattern organizes the objects in the manner to represent the part-whole hierarchies in a traditional two-tier hierarchy.

The [http://www.soapatterns.org/agnostic_subcontroller.asp agnostic sub-controller] implements the service composability but it differs from the composite pattern in such a way that cross-entity functionality is abstracted and made accessible through the sub –controller capability.

For instance, the traditional composite pattern has the object representing a part-whole hierarchy as in the below figure of graphic class which has draw(). If we require a cross-entity functionality as in the below figure, we require a colored rectangle, we require the functionality fill() of color class. Hence the sub-controller module is created which has the functionality of different parents, thus making it reusable.

figure to illustrate above difference

[[Image:Composite_example.png]]

2)
The traditional bridge pattern separates the abstraction from its implementation in order to vary independently. Whereas the canonical protocol avoids the protocol bridging in such a way that there is a single communication technology through which the services can interact.
In the below figure of bridge pattern, the relationship between the abstraction and implementor is bridge and it results the implementor to vary independently from the abstraction by having different ConcreteImplementor. The canonical protocol avoids the variation by having a single communication technology between different objects.

figure for above difference

[[Image:Traditional_bridge.png]]
Figure for Traditional bridge pattern

For canonical protocol refer to the explanation given in example design patterns

3) The traditional builder pattern decouples the construction of the object from its representation so that the same construction process can be used to develop different representations. The different representations (contracts) are addressed in SOA by the Concurrent Contracts with the application of Service-façade design pattern. With service-façade design pattern, an abstraction is created to support the interaction between different contracts. As a result, different contracts can be created for a single service.
In the below figure, the conversion of the text document is separated from the reader of RTF document, so that the text document can be represented in different forms like ASCIIText, TeXText and TextWidget. The different representation is achieved by decoupling of construction and abstraction. In the case of concurrent contracts pattern, the different contracts or services (invoices) are created for different consumer through service-façade by creating a new abstraction.

[[Image:Builder.png]]
Figure for Traditional Builder pattern

[[Image:Concurrent_pattern.png]]
Figure for Concurrent pattern

==Similarities==
1) The Service-façade design pattern is similar to the façade (traditional) pattern in the manner that it implements the façade logic which is creating an abstraction for intra-communication within objects to the service architecture. The advantage by adding the façade logic to the service architecture is that it preserves the underlying logic from run-time changes.

2) The UI Mediator design pattern implements the mediator logic of traditional mediator pattern. The mediator logic aims to provide the user responses in a way that user understands, independently of what the underlying services perform.

3) The Intermediate routing pattern in SOA is similar to Decorator pattern (traditional) in the functionality that it adds the required logic at run-time. The decorator adds the additional functionality to the object at run-time. The intermediate routing pattern is about placing the routing logic to address the run-time scenarios.

4)The Capability Composition pattern in SOA implements the Composite pattern (traditional). The Capability Composition is about composing one or more capabilities outside the service’s context to address the large, complex problem.

5) The Decoupled Contract pattern implements the traditional Bridge pattern in the manner that service contract is separated from the implementation. The Bridge pattern decouples the abstraction from implementation to facilitate the variation of both (abstraction and implementation).

6) The Legacy Wrapper pattern is related to traditional Adapter pattern. The Legacy Wrapper pattern protects the legacy logic by providing a standard service that takes of protecting the legacy details by encapsulating, extraction or elimination. The encapsulation, extraction or elimination is done in order to change the service as the consumer requires it. This is related to adapter in a way that it converts the interface of one class to another as the client expects.

=Summary=

=Glossary=

1.Serive : "A service is a discoverable resource that executes a repeatable task, and is described by an externalized service specification."

2.[http://www.ibm.com/developerworks/webservices/library/ws-soa-term1/ SOA Terminology]

3.SOA :[http://en.wikipedia.org/wiki/Service-oriented_architecture Service oriented Architecture]

4.API :[http://en.wikipedia.org/wiki/Application_programming_interface Application programming interface]

5.SOAP :[http://en.wikipedia.org/wiki/SOAP Simple Object Access Protocol]

6.HTTP :[http://en.wikipedia.org/wiki/HyperText_Transfer_Protocol Hypertext Transfer Protocol]

7.GoF :[http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Gang of Four]

8.[http://soaglossary.com/ SOA Glossory]

=References=

1.[http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Design patterns for object oriented software]

2.[http://en.wikipedia.org/wiki/Service-oriented_architecture#Introduction Service Oriented Architecture]

3.[http://www.exforsys.com/tutorials/soa/soa-definitions-and-certification.html SOA Tutorial]

4.[http://www.soapatterns.org/ soa design patterns]

5.[http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29 design pattern]

6.[http://www.oracle.com/technologies/soa/center.html oracle SOA centre]

7.[http://www.ibm.com/developerworks/webservices/library/ws-soa-term1/ IBMs SOA Contributions]

8.[http://www.oracle.com/technology/pub/articles/erl_soa_design_patterns_app_sequences.html SOA Design patterns application sequences by oracle]

CSC/ECE 517 Fall 2009/wiki2 16 rs

2009-10-10T01:42:23Z

Screenit: /* Introduction */

CSC/ECE 517 Fall 2009/wiki2 16 rs

SOA provides another view of providing functionality based upon services offered in terms of protocols and a specific API. Research and report on what patterns have been proposed and are utilized within this domain. How do they differ from traditional design patterns proposed by Eric Gamma, Richard Helm, Ralph Johnson, and John Vlissides? How are they similar?

----
=Introduction=

This article focuses on the design patterns which are proposed and utilized in the [http://en.wikipedia.org/wiki/Service_oriented_architecture Service Oriented Architecture]. As the SOA provides its services through the protocols and API, this article throws light on the design patterns that specifically provide services through protocols like Canonical protocol, Dual protocol and Protocol Bridging. In a broader perspective, other design patterns have been explained tersely. In addition to explanation of the SOA design patterns, this compares the SOA design patterns with the traditional design patterns proposed by the ‘Gang of Four’ (Eric Gamma, Richard Helm, Ralph Johnson, and John Vlissides) and comes up with the differences and similarities between them.

=Service Oriented Architecture-An Overview=

==SOA-Definition==

A service-oriented architecture is essentially a collection of services. These services communicate with each other.The communication can involve either simple data passing or it could involve two or more services coordinating some activity. Some means of connecting services to each other is needed.Rather than defining an API, SOA defines the interface in terms of protocols and functionality. An endpoint is the entry point to such an SOA implementation.Service-orientation requires loose coupling of services with operating systems, and other technologies that underlie applications. SOA separates functions into distinct units, or services, which developers make accessible over a network in order to allow users to combine and reuse them in the production of applications. These services communicate with each other by passing data from one service to another, or by coordinating an activity between two or more services.

==Why SOA?==

Vast majority of Businesses working in the field of Information Technology have to justify their projects with a return on their investments. This puts Information Technology, as a field under enormous pressure. Information Technology must boast requirements that are increasingly responsive and flexible to the shifting needs of different Businesses.

Firms dealing with Information Technology must also be able to face the challenge of taking on an array of software systems that may or may not be compatible with one another. Moreover, Information Technology has to face demands to bring new commercial services to a much wider array of customers. Customers may access services through web interfaces, or may be part of a supply chain that needs to decrease the time and cost of manufacturing.

Thus, Information Technology companies are always on the look out for solutions that will help them meet the above demands – without having to spend a lot of money.SOA offers a solution to satisfy the above needs of the industry

==SOA-Benifits==
In architectural terms, a modern architectural design should be Service Oriented, loosely coupled, driven by events, able to support both integration and assembly, aligned with valuable life cycle support processes, and able to leverage existing infrastructure and applications.

When it comes to Service Oriented Architecture, it tends to offer a variety of different advantages over more traditional methods of distributing computing. These include offering business services across several platforms; providing location independence; providing authentication as well as authorization support on ever tier; a loosely coupled approach; and dynamic search and connectivity to other services. At the same time, it allows that services do not have to be located on a particular system or network.

=Design Patterns in SOA=
A design pattern is a general reusable solution to a commonly occurring problem in software design. A design pattern is not a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations.Design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved.

Design patterns play a major role in SOA. The implementation and deployment of SOA designs provide different challenges during product development life cycle.Such challenges made may SOA projects to be discontinued. Design patterns help in overcoming these problems by providing a solution to the problems posed.Each SOA design pattern provides a design solution in support of
successfully applying service orientation and establishing a quality
service-oriented architecture

=Design Patterns proposed =

The proposed Design Patterns for SOA fall in to following categories.They are listed below and corresponding patterns in
each category are given.

[http://www.soapatterns.org/masterlist_c.asp#ch6 Foundational Inventory Patterns]

These design patterns focus on providing solutions to the problems like maximizing re-composition and avoiding redundant logic .

examples for this category are Enterprise Inventory,Domain Inventory,Service Normalization,Logic Centralization, Service Layers Canonical Protocol,Canonical Schema

[http://www.soapatterns.org/masterlist_c.asp#ch7 Logical Inventory Layer Patterns]

These design patterns provide the solution to the problem of how can business logic be separated, reused, and governed independently?

examples for this category are Utility Abstraction,Entity Abstraction,Process Abstraction

[http://www.soapatterns.org/masterlist_c.asp#ch8 Inventory Centralization Patterns]

These patterns focus on providing solution for aspect of governing business logic etc

examples for this category are Process Centralization,Schema Centralization,Policy Centralization,Rules Centralization.

[http://www.soapatterns.org/masterlist_c.asp#ch9 Inventory Implementation Patterns]

These patterns help to solve implementation problems like limitations introduced by communication technology. Example like a single protocol may not accommodate all requirements etc

examples for this category are Dual Protocols,Canonical Resources,State Repository,Stateful Services,Service Grid,Inventory Endpoint,Cross-Domain Utility Layer

[http://www.soapatterns.org/masterlist_c.asp#ch10 Inventory Governance Patterns]

The patterns deal with the governance problems caused by service contract within the same service inventory

examples for this category are Canonical Expression,Metadata Centralization,Canonical Versioning

[http://www.soapatterns.org/masterlist_c.asp#ch11 Foundational Service Patterns]

The patterns proposed in this category focus on solving large business problems without having to build a stand alone solution.

examples for this category are Functional Decomposition,Service Encapsulation,Agnostic Context,Non-Agnostic Context,Agnostic Capability

[http://www.soapatterns.org/masterlist_c.asp#ch12 Service Implementation Patterns]

The patterns in this category focus on improving the realiability and availability of the service

examples for this category are Service Facade,Redundant Implementation,Service Data Replication,Partial State Deferral,Partial Validation,UI Mediator

[http://www.soapatterns.org/masterlist_c.asp#ch13 Service Security Patterns]

The patterns proposed in this category deal with the problem of data encapsulation and security aspects.

examples for this category are Exception Shielding,Message Screening,Trusted Subsystem ,Service Perimeter Guard

[http://www.soapatterns.org/masterlist_c.asp#ch14 Service Contract Design Patterns]

The patterns proposed in this category focus on providing solution for how to make the service contract suitable for all potential customers,make it aligned with other services etc

examples for this category are Decoupled Contract,Contract Centralization,Contract De normalization,Concurrent Contracts,Validation Abstraction

[http://www.soapatterns.org/masterlist_c.asp#ch15 Legacy Encapsulation Patterns]

The patterns proposed deals with the problems in legacy systems like processing of data contained in flat files, redundancy resulting in delivery to multiple channels etc

examples for this category are Legacy Wrapper, Multi-Channel Endpoint,File Gateway

[http://www.soapatterns.org/masterlist_c.asp#ch16 Service Governance Patterns]

These patterns provide solution for problems like updating the customers with changed service so that they are not affected, modifications in service etc

examples for this category are Compatible Change,Version Identification,Termination Notification,Service Refactoring,Service Decomposition,Proxy Capability,Decomposed Capability,Distributed Capability

[http://www.soapatterns.org/masterlist_c.asp#ch17 Capability Composition Patterns]

The pattern proposed focuses on the problem of How can a service capability solve a problem that requires logic outside of the service boundary and How can the same capability be used to help solve multiple problems?

examples for this category are Capability Composition,Capability Recomposition

[http://www.soapatterns.org/masterlist_c.asp#ch18 Service Messaging Patterns]

The patterns proposed in this category focus on setting up of message framework for transfer of data.

examples in this category are Service Messaging,Messaging Metadata,Service Agent,Intermediate Routing,State Messaging,Service Callback,Service Instance Routing,Asynchronous Queuing,Reliable Messaging,Event-Driven Messaging.

[http://www.soapatterns.org/masterlist_c.asp#ch19 Composition Implementation Patterns]

The patterns proposed in this category focus on problems during runtime like runtime activities that span multiple services fail, the parent business task is incomplete etc

examples for this category are Agnostic SubController,Composition Autonomy,Atomic Service Transaction,Compensating ServiceTransaction

[http://www.soapatterns.org/masterlist_c.asp#ch20 Service Interaction Security Patterns]

The proposed patterns in this category are focused on security methods like encryption,decryption,authenticating the data,consumer and service

examples for this category are Data Confidentiality, Data Origin Authentication, Direct Authentication, Brokered Authentication

[http://www.soapatterns.org/masterlist_c.asp#ch21 Transformation Patterns]

The Patterns proposed in this category concrete on how data from one data model can be dynamically converted to comply to a different data model.

examples for this category are Data Model Transformation,Data Format Transformation, Protocol Bridging

[http://www.soapatterns.org/masterlist_c.asp#ch22 Common Compound Design Patterns]

A compound pattern is a coarse-grained pattern comprised of a set of finer-grained patterns.

examples for this category are Orchestration,Enterprise Service Bus,Service Broker,Canonical Schema Bus,Official Endpoint,Federated Endpoint Layer,Three-Layer Inventory

=Example Design Patterns =

The following section describes five design patterns which are utilized in SOA.The described patterns provide the problem and corresponding solution

==Canonical protocol==

[[Image:Canonicalpattern.jpg.png]]

Problem: Services that support different communication technologies compromise interoperability, limit the quantity of potential consumers, and introduce the need for undesirable protocol bridging measures.

Solution: The architecture establishes a single communications technology as the sole or primary medium by which services can interact.

From the above figure it is observed that though still delivered by different projects via different vendor platforms A,B,C etc these services conform to one centralized communications technology, making them technologically compatible.

==Dual protocol==

[[Image:dualprotocol.png]]

Problem: Canonical Protocol requires that all services conform to the use of the same communications technology; however, a single protocol may not be able to accommodate all service requirements, thereby introducing limitations.

Solution: The service inventory architecture is designed to support services based on primary and secondary protocols.

Regardless of protocol, all services must invoke each other via their official service contracts (A, B). Bypassing the contract may seem convenient when the underlying service logic of the primary service supports the same protocol as the secondary service (C), but it is an anti-pattern that will eventually inhibit the application of this pattern and further weaken the overall service inventory foundation.

==Protocol Bridging==

[[Image:protocolbridging.png]]

Problem: Services using different communication protocols or different versions of the same protocol cannot exchange data.

Solution: Bridging logic is introduced to enable communication between different communication protocols by dynamically converting one protocol to another at runtime.

From the above figure it can be noticed that the consumer programs interact with a middle-tier broker that provides protocol bridging features. Separate protocol adapters are used to translate the two incompatible protocols to the required SOAP version 1.2 over HTTP. The broker then transmits the messages to the service on behalf of the consumers.

==UI Mediator==

[[Image:uimediator.png]]

Problem: Because the behavior of individual services can vary depending on their design,runtime usage, and the workload required to carry out a given capability, the consistency with which a service-oriented solution can respond to requests originating from a user-interface can fluctuate, leading to a poor user experience.

Solution: Establish mediator logic solely responsible for ensuring timely interaction and feedback with user-interfaces and presentation logic.

The mediator service (D) regularly updates the user interface while services A, B, and C work behind-the-scenes to complete the task

==Service Facade==

[[Image:service_facade.png]]

Problem: The coupling of the core service logic to contracts and implementation resources can inhibit its evolution and negatively impact service consumers.

Solution: A service facade component is used to abstract a part of the service architecture with negative coupling potential.

Facade logic is placed in between the contract and the core service logic. This allows the core service logic to remain decoupled from the contract.

=Similarities and Differences Between Patterns for SOA and Traditional pattens proposed by GoF=

The Gang of Four(Gof) comprising of Eric Gamma, Richard Helm, Ralph Johnson, and John Vlissides have documented the design patterns that were followed by Software developers and architects in object oriented space. They have documented 23 design patterns which are collectively called as Traditional design patterns.

The design patterns in SOA are similiar in some aspects to the traditional patterns.They also differ from the traditional patterns. The similiarities and differences between them are provided in this section

==Differences==

The differences between the SOA design patterns and traditional design patterns have been come up based on the individual functionality that each pattern provide. Following are the differences,

1) The composite pattern organizes the objects in the manner to represent the part-whole hierarchies in a traditional two-tier hierarchy.

The [http://www.soapatterns.org/agnostic_subcontroller.asp agnostic sub-controller] implements the service composability but it differs from the composite pattern in such a way that cross-entity functionality is abstracted and made accessible through the sub –controller capability.

For instance, the traditional composite pattern has the object representing a part-whole hierarchy as in the below figure of graphic class which has draw(). If we require a cross-entity functionality as in the below figure, we require a colored rectangle, we require the functionality fill() of color class. Hence the sub-controller module is created which has the functionality of different parents, thus making it reusable.

figure to illustrate above difference

[[Image:Composite_example.png]]

2)
The traditional bridge pattern separates the abstraction from its implementation in order to vary independently. Whereas the canonical protocol avoids the protocol bridging in such a way that there is a single communication technology through which the services can interact.
In the below figure of bridge pattern, the relationship between the abstraction and implementor is bridge and it results the implementor to vary independently from the abstraction by having different ConcreteImplementor. The canonical protocol avoids the variation by having a single communication technology between different objects.

figure for above difference

[[Image:Traditional_bridge.png]]
Figure for Traditional bridge pattern

For canonical protocol refer to the explanation given in example design patterns

3) The traditional builder pattern decouples the construction of the object from its representation so that the same construction process can be used to develop different representations. The different representations (contracts) are addressed in SOA by the Concurrent Contracts with the application of Service-façade design pattern. With service-façade design pattern, an abstraction is created to support the interaction between different contracts. As a result, different contracts can be created for a single service.
In the below figure, the conversion of the text document is separated from the reader of RTF document, so that the text document can be represented in different forms like ASCIIText, TeXText and TextWidget. The different representation is achieved by decoupling of construction and abstraction. In the case of concurrent contracts pattern, the different contracts or services (invoices) are created for different consumer through service-façade by creating a new abstraction.

[[Image:Builder.png]]
Figure for Traditional Builder pattern

[[Image:Concurrent_pattern.png]]
Figure for Concurrent pattern

==Similarities==
1) The Service-façade design pattern is similar to the façade (traditional) pattern in the manner that it implements the façade logic which is creating an abstraction for intra-communication within objects to the service architecture. The advantage by adding the façade logic to the service architecture is that it preserves the underlying logic from run-time changes.

2) The UI Mediator design pattern implements the mediator logic of traditional mediator pattern. The mediator logic aims to provide the user responses in a way that user understands, independently of what the underlying services perform.

3) The Intermediate routing pattern in SOA is similar to Decorator pattern (traditional) in the functionality that it adds the required logic at run-time. The decorator adds the additional functionality to the object at run-time. The intermediate routing pattern is about placing the routing logic to address the run-time scenarios.

4)The Capability Composition pattern in SOA implements the Composite pattern (traditional). The Capability Composition is about composing one or more capabilities outside the service’s context to address the large, complex problem.

5) The Decoupled Contract pattern implements the traditional Bridge pattern in the manner that service contract is separated from the implementation. The Bridge pattern decouples the abstraction from implementation to facilitate the variation of both (abstraction and implementation).

6) The Legacy Wrapper pattern is related to traditional Adapter pattern. The Legacy Wrapper pattern protects the legacy logic by providing a standard service that takes of protecting the legacy details by encapsulating, extraction or elimination. The encapsulation, extraction or elimination is done in order to change the service as the consumer requires it. This is related to adapter in a way that it converts the interface of one class to another as the client expects.

=Summary=

=Glossary=

1.Serive : "A service is a discoverable resource that executes a repeatable task, and is described by an externalized service specification."

2.[http://www.ibm.com/developerworks/webservices/library/ws-soa-term1/ SOA Terminology]

3.SOA :[http://en.wikipedia.org/wiki/Service-oriented_architecture Service oriented Architecture]

4.API :[http://en.wikipedia.org/wiki/Application_programming_interface Application programming interface]

5.SOAP :[http://en.wikipedia.org/wiki/SOAP Simple Object Access Protocol]

6.HTTP :[http://en.wikipedia.org/wiki/HyperText_Transfer_Protocol Hypertext Transfer Protocol]

7.GoF :[http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Gang of Four]

8.[http://soaglossary.com/ SOA Glossory]

=References=

1.[http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Design patterns for object oriented software]

2.[http://en.wikipedia.org/wiki/Service-oriented_architecture#Introduction Service Oriented Architecture]

3.[http://www.exforsys.com/tutorials/soa/soa-definitions-and-certification.html SOA Tutorial]

4.[http://www.soapatterns.org/ soa design patterns]

5.[http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29 design pattern]

6.[http://www.oracle.com/technologies/soa/center.html oracle SOA centre]

7.[http://www.ibm.com/developerworks/webservices/library/ws-soa-term1/ IBMs SOA Contributions]

8.[http://www.oracle.com/technology/pub/articles/erl_soa_design_patterns_app_sequences.html SOA Design patterns application sequences by oracle]

CSC/ECE 517 Fall 2009/wiki1a 9 DS

2009-09-16T02:56:45Z

Screenit:

'''Refactoring Tools - Academic Underpinnings and Improvement Initiatives'''

----

== Definition ==

Refactoring[http://en.wikipedia.org/wiki/Code_refactoring] is defined as the technique by which the existing body of the code is restructured by changing the inner structure and preserving its external behavior. More common refactorings that are available can be found here [http://www.refactoring.com/catalog/index.html]. The tools which are used to achieve this purpose are commonly known as refactoring tools.

Refactoring tools are provided as Integrated Development Environment (IDE) features currently and are available for all popular programming languages. For instance, the common IDEs that provide the refactoring tools are IBM’s Eclipse, Sun’s Netbeans and IntelliJ’s IDEA.

Below is an example of refactoring "extract method"

Code Before refactoring

public class Refactoringjava {
public static void main(String args[]){
int a = 0,b =2,result;
result = a+b;
System.out.println("Sum =" + result);
}

Code after Refactoring

public class Refactoringjava {
public static void main(String args[]){
int a = 0,b =2,result;
result = sum(a,b);
System.out.println("Sum =" + result);
}
static int sum(int x,int y)
{
int sum = x+y;
return(sum);
}

== Overview ==
This deals with the academic underpinnings of refactoring starting from its evolution and the initiatives taken to improve the current generation of refactoring tools.In addition, this discusses the on going research initiatives to enhance the features in refactoring tools. It also throws lights up on various books, academic thesis, conferences and workshops on the topic of refactoring.

== Academic Underpinnings ==

=== '''Motivation''' ===

The first official thesis on the area of refactoring leads back to 1992 when Bill Opdyke finished his thesis on the topic "Refactoring Object-Oriented Frameworks"[http://portal.acm.org/citation.cfm?id=169783&dl=GUIDE&coll=GUIDE&CFID=50708246&CFTOKEN=47231553]. Bill Opdyke was working in Bell Laboratories developing electronic switching systems.
When he started to pursue his doctoral studies he wanted it to be related to practical business applications. That is when he narrowed down on this topic which led to the official shaping of the cloud refactoring.

The Basic motivation behind the emergence of refactoring was the software re-usability and cutting down cost involved in restructuring software for various purposes. Thus refactoring leads to software reuse in future.

Though it might appear that refactoring began in research labs it actually emerged on an ad-hoc basis when object-oriented programmers came across situations where they felt the need for change in object oriented software. Refactoring actually has its roots way back. Factoring was a key technique in Forth Language from its birth in 70’s. Absence of appropriate syntax made it not possible to extract the best use out of it. Ralph Johnson was the first person to use the name refactoring in print. Along with Bill Opdyke he published a paper on refactoring in 1990.

=== '''Etymology''' ===

The first known use of the term “refactoring” appeared in “Refactoring: An Aid in Designing Application Frameworks and Evolving Object-Oriented Systems” by Ralph Johnson and Bill Opdyke in 1990. But Refactoring as a function and as a technique, was almost certainly used before then.

=== '''More Works''' ===

Lot of work has been done on this area which includes the thesis work “Practical Analysis for refactoring” [http://portal.acm.org/citation.cfm?id=871251] by Donald Bradley Roberts. It focuses on several ways to make a refactoring tool that is both fast and reliable enough to be useful. In another thesis work “Refactoring as Formal Refinements” [http://dsc.upe.br/~mlc/PhDThesis/RefactoringsAsFormalRefinements.pdf] by Márcio Cornélio throws light on algebraic technique that presents refactoring as behavior preserving transformation. For list of other thesis works and papers refer to the References section.

=== '''Books on Refactoring''' ===

Various books are available on the topic of refactoring these days. The initial list of books includes “Refactoring: Improving the Design of Existing Code“ [http://www.amazon.com/exec/obidos/ASIN/0201485672] by Martin Flower and Refactoring to Patterns [http://www.industriallogic.com/xp/refactoring/] by Joshua Kerievsky and many more books on this topic. For listing of books on refactoring refer to the external links.

== Initiatives taken to improve current generation of refactoring tools ==

Various initiatives like conferences, workshops are conducted by Organizations like Institute of Electrical and Electronics Engineers (IEEE), Associate for Computing Machinery (ACM) to improve the current generation of refactoring tools. The first initiative taken to improve the current generation of refactoring tools was the creation of the refactoring research web portal ([http://refactoring.info]).
This research web portal includes a collection of links and articles that provide the researchers and industrial engineers an up-to-date knowledge on refactoring.

=== '''Workshops and Conferences''' ===

The second initiative taken was, organization of workshops which serve as a forum to bring researchers and tool vendors together for collaborative efforts in developing the refactoring tools. This initiative has been taken with the motive to develop the tool support for refactoring efficiently by combining the state-of-the-art research with the challenges from real-time applications. The benefits of such workshops by collaborating the researchers and tool vendors are, to develop the tools in a short period of time and to eliminate the redundant works by other researchers and tool vendors. The workshops on refactoring tools are being conducted annually at various places

The first workshop on refactoring tools was conducted on July 31st 2007 in conjunction with European Conference on Object-Oriented Programming (ECOOP) [https://netfiles.uiuc.edu/dig/RefactoringWorkshop/] at Berlin. Various papers like automated refactoring for improved cohesion, reuse based refactoring tools, Engineering reusability for software refactoring tools and others were presented and discussed. The proceedings of the first workshop can be found as a TU Berlin Technical Report, ISSN 1436-9915.

The second workshop on refactoring tools was conducted on October 19th 2008 in conjunction with Object-Oriented Programming Systems, Languages and Applications (OOPSLA) [https://netfiles.uiuc.edu/dig/RefactoringInfo/WRT08/] at Nashville, Tennessee. Various papers that were accepted and discussed were Cross Language Refactoring for Eclipse plug-ins, Tool support for refactoring functional programs, Towards a Refactoring guideline using code clone classification and others. More accepted papers at the second workshop can be found at [https://agora.cs.illinois.edu/display/wrt08/Accepted+Papers]. The interest in research in refactoring tools has increased to a greater extent that more papers were submitted and more researchers and tool vendors like JetBrains, Microsoft participated at the workshop.

The third workshop on refactoring tools is going to be held on October 25-29, 2009 in conjunction with Object-Oriented Programming Systems, Languages and Applications (OOPSLA) [https://netfiles.uiuc.edu/dig/RefactoringInfo/WRT09/] at Orlando, Florida. The papers have been invited for the topics which include language-independent transformation frameworks, language-independent analysis frameworks and analytical representations.

=== '''Ongoing Research''' ===

Refactoring in general preserves the behavior of the program during restructuring. But with the metaphor of extended language, the refactoring can be done in an efficient manner. The extended language implementation technique is all about embedding the source code into the extended language where the refactoring is easier to perform and then translating the refactored code into original language. This has been implemented on the well-known refactoring ‘Extract Method’ which showed the results that overall refactoring can be decomposed into micro-refactorings which are easy to implement and test.

Another improvement in which a tool can provide is the refactoring based on invariant preservation rather on the regular pre-condition based. The program invariants are nothing but the predicates about the objects state and their relationships which remain valid for every execution of program. There are quite a few initiatives that can be taken as part of the future research, which include the structural refactorings ‘Encapsulate Field’[http://sourcemaking.com/refactoring/encapsulate-field] or ‘Move Method’[http://www.refactoring.com/catalog/moveMethod.html] implementation using the micro-refactoring (refactorings which are used to perform small restructuring at once) decomposition approach. The above research is being conducted by the Programming Tools Group at University of Oxford.More information on this research can be found at [http://progtools.comlab.ox.ac.uk/projects/refactoring/ecoop09.pdf]

Lots of initiatives are being taken by tool vendors to improve refactoring tools. One such case is Net Beans where research is being carried on in this arena. The “replace method code duplicate” feature is being designed to locate selected method code repetitions and turn them in to a method call. The “generify” feature is currently developed for the transformation of non – generic code in to generic aware code. The “copy class” feature is currently in experimental stage to tap the feature of refactoring that allows to copy an existing class or interface. Likewise other features like “Inline method” which is used to inline a method, “Introduce variable” and “Clean up” are currently developed in their labs.

=== '''Survey On Refactoring Tools''' ===

In general,survey is one form of an initiative taken to improve any development environment.It includes complete analysis of an given environment and highlights various features like the current trend, future scope and limitations. All these helps in the potential development of an efficient environment. Likewise survey has been done on refactoring tools which compares the refactoring tools support on various IDE's , which includes Eclipse,Net Beans and IDEA. This survey gives an idea of which IDE supports the specific refactoring in an efficient manner. For more information about the findings please refer to "Refactoring Tools and Complementary Techniques"[http://www2.computer.org/portal/web/csdl/doi/10.1109/AICCSA.2006.205164]

=== '''Other Initiatives''' ===

Apart from workshops held specifically for refactoring tools, other conferences have been organized by Automated Software Engineering (ASE), International Conference on Software Engineering (ICSE), Foundations of Software Engineering (FSE) wherein papers on refactoring have been presented and awarded the best paper award.

In addition to the workshops and conferences, the weekly contest on refactoring “Refactor It! The Weekly Book Giveaway” has been started by Billy McCafferty to increase the awareness and interest among the software developers, students and other programming communities. Various groups like Software Architecture Group (SAG) at University of Illinois at Urbana-Champaign, Program Analysis and Transformation (PAT) group at IBM TJ Watson Research Center have been organized at Universities and Organizations to conduct research in refactoring tools and to improve the current generation of refactoring tools. More details about various groups and people can be found at [https://netfiles.uiuc.edu/dig/RefactoringInfo/people.html]

== External Links ==

Refactor It contest [http://devlicio.us/blogs/billy_mccafferty/archive/2006/11/13/refactor-it-the-weekly-book-giveaway.aspx]

Refactoring tool for .NET [http://submain.com/products/codeit.once.aspx]

=== '''Books''' ===

Refactoring Workbook - William.C.Wake [http://www.amazon.com/exec/obidos/tg/detail/-/0321109295]

Refactoring to Patterns - [http://industriallogic.com/xp/refactoring/]

Refactoring Databases : Evolutionary Database Design - [http://www.amazon.com/exec/obidos/ASIN/0321293533]

Professional Refactoring in Visual Basic - [http://www.amazon.com/gp/product/0470179791]

CoreJ2EE Patterns - [http://www.amazon.com/Core-J2EE-Patterns-Practices-Strategies/dp/0131422464]

== References ==

=== '''Thesis Works''' ===

William F. Opdyke, Refactoring object-oriented frameworks, University of Illinois at Urbana-Champaign, Champaign, IL, 1992 [http://portal.acm.org/citation.cfm?id=169783&dl=GUIDE&coll=GUIDE&CFID=50708246&CFTOKEN=47231553]

Refactoring as Formal Refinements- Marico Lopes Cornelio [http://dsc.upe.br/~mlc/PhDThesis/RefactoringsAsFormalRefinements.pdf]

Practical Analysis for Refactoring – Donald B Roberts, University of Illinois at Urbana-Champaign Champaign, IL, USA[http://portal.acm.org/citation.cfm?id=871251]

Refactoring Tools and Complementary Techniques - Martin Drozdz, Derrick G Kourie, Bruce W Watson, Andrew Boake Espresso Research Group, Department of Computer Science, University of Pretoria, Pretoria, South Africa 0001 [http://www2.computer.org/portal/web/csdl/doi/10.1109/AICCSA.2006.205164]

=== '''Other Papers/Conferences''' ===

William F. Opdyke and Ralph E. Johnson. Refactoring: An aid in designing application frameworks and evolving object-oriented systems. In Proceedings of Symposium on Object- Oriented Programming Emphasizing Practical Applications (SOOPPA), September 1990.

Refactoring, Reuse & Reality, Bill Opdyke, Lucent Technologies/ Bell Labs, Copyright 1999, Lucent Technologies[http://chip.cs.uiuc.edu/users/opdyke/wfo.990201.refac.html]

Why Don’t People Use Refactoring Tools? Emerson Murphy-Hill and Andrew P. Black, Portland State University [http://web.cecs.pdx.edu/~black/publications/WRT07.pdf?id=1176678&type=pdf&coll=&dl=acm&CFID=15151515&CFTOKEN=6184618]

First workshop on refactoring in conjunction with ecoop Berlin 07 [https://netfiles.uiuc.edu/dig/RefactoringWorkshop/]

Second ACM Workshop on Refactoring Tools (WRT'08)[https://netfiles.uiuc.edu/dig/RefactoringInfo/WRT08/]

Accepted papers for WRT’08 [https://agora.cs.illinois.edu/display/wrt08/Accepted+Papers]

Third ACM Workshop on Refactoring Tools (WRT'09)[https://netfiles.uiuc.edu/dig/RefactoringInfo/WRT09/]

ACM SIGSOFT 2006 / FSE 14[http://www.cs.uoregon.edu/fse-14/]

29th Int. Conference on Software Engineering® 20 - 26 May 2007[http://web4.cs.ucl.ac.uk/icse07/]

21st IEEE/ACM International Conference on Automated Software Engineering[http://ase.cs.uni-essen.de/ase/past/ase2006/]

=== '''Web''' ===

Refactoring Info[https://netfiles.uiuc.edu/dig/RefactoringInfo/index.html]

www.refactoring.com [http://www.refactoring.com/]

Refactoring at AllExperts [http://en.allexperts.com/e/r/re/refactoring.html]

Refactoring Tool - NetBeans [http://refactoring.netbeans.org/]

CSC/ECE 517 Fall 2009/wiki1a 9 DS

2009-09-16T02:56:23Z

Screenit: /* '''Survey On Refactoring Tools''' */

CSC/ECE 517 Fall 2009/wiki1a 9 DS

2009-09-16T02:54:26Z

Screenit: /* '''Survey On Refactoring Tools''' */

'''Refactoring Tools - Academic Underpinnings and Improvement Initiatives'''

----

== Definition ==

Refactoring[http://en.wikipedia.org/wiki/Code_refactoring] is defined as the technique by which the existing body of the code is restructured by changing the inner structure and preserving its external behavior. More common refactorings that are available can be found here [http://www.refactoring.com/catalog/index.html]. The tools which are used to achieve this purpose are commonly known as refactoring tools.

Refactoring tools are provided as Integrated Development Environment (IDE) features currently and are available for all popular programming languages. For instance, the common IDEs that provide the refactoring tools are IBM’s Eclipse, Sun’s Netbeans and IntelliJ’s IDEA.

Below is an example of refactoring "extract method"

Code Before refactoring

public class Refactoringjava {
public static void main(String args[]){
int a = 0,b =2,result;
result = a+b;
System.out.println("Sum =" + result);
}

Code after Refactoring

public class Refactoringjava {
public static void main(String args[]){
int a = 0,b =2,result;
result = sum(a,b);
System.out.println("Sum =" + result);
}
static int sum(int x,int y)
{
int sum = x+y;
return(sum);
}

== Overview ==
This deals with the academic underpinnings of refactoring starting from its evolution and the initiatives taken to improve the current generation of refactoring tools.In addition, this discusses the on going research initiatives to enhance the features in refactoring tools. It also throws lights up on various books, academic thesis, conferences and workshops on the topic of refactoring.

== Academic Underpinnings ==

=== '''Motivation''' ===

The first official thesis on the area of refactoring leads back to 1992 when Bill Opdyke finished his thesis on the topic "Refactoring Object-Oriented Frameworks"[http://portal.acm.org/citation.cfm?id=169783&dl=GUIDE&coll=GUIDE&CFID=50708246&CFTOKEN=47231553]. Bill Opdyke was working in Bell Laboratories developing electronic switching systems.
When he started to pursue his doctoral studies he wanted it to be related to practical business applications. That is when he narrowed down on this topic which led to the official shaping of the cloud refactoring.

The Basic motivation behind the emergence of refactoring was the software re-usability and cutting down cost involved in restructuring software for various purposes. Thus refactoring leads to software reuse in future.

Though it might appear that refactoring began in research labs it actually emerged on an ad-hoc basis when object-oriented programmers came across situations where they felt the need for change in object oriented software. Refactoring actually has its roots way back. Factoring was a key technique in Forth Language from its birth in 70’s. Absence of appropriate syntax made it not possible to extract the best use out of it. Ralph Johnson was the first person to use the name refactoring in print. Along with Bill Opdyke he published a paper on refactoring in 1990.

=== '''Etymology''' ===

The first known use of the term “refactoring” appeared in “Refactoring: An Aid in Designing Application Frameworks and Evolving Object-Oriented Systems” by Ralph Johnson and Bill Opdyke in 1990. But Refactoring as a function and as a technique, was almost certainly used before then.

=== '''More Works''' ===

Lot of work has been done on this area which includes the thesis work “Practical Analysis for refactoring” [http://portal.acm.org/citation.cfm?id=871251] by Donald Bradley Roberts. It focuses on several ways to make a refactoring tool that is both fast and reliable enough to be useful. In another thesis work “Refactoring as Formal Refinements” [http://dsc.upe.br/~mlc/PhDThesis/RefactoringsAsFormalRefinements.pdf] by Márcio Cornélio throws light on algebraic technique that presents refactoring as behavior preserving transformation. For list of other thesis works and papers refer to the References section.

=== '''Books on Refactoring''' ===

Various books are available on the topic of refactoring these days. The initial list of books includes “Refactoring: Improving the Design of Existing Code“ [http://www.amazon.com/exec/obidos/ASIN/0201485672] by Martin Flower and Refactoring to Patterns [http://www.industriallogic.com/xp/refactoring/] by Joshua Kerievsky and many more books on this topic. For listing of books on refactoring refer to the external links.

== Initiatives taken to improve current generation of refactoring tools ==

Various initiatives like conferences, workshops are conducted by Organizations like Institute of Electrical and Electronics Engineers (IEEE), Associate for Computing Machinery (ACM) to improve the current generation of refactoring tools. The first initiative taken to improve the current generation of refactoring tools was the creation of the refactoring research web portal ([http://refactoring.info]).
This research web portal includes a collection of links and articles that provide the researchers and industrial engineers an up-to-date knowledge on refactoring.

=== '''Workshops and Conferences''' ===

The second initiative taken was, organization of workshops which serve as a forum to bring researchers and tool vendors together for collaborative efforts in developing the refactoring tools. This initiative has been taken with the motive to develop the tool support for refactoring efficiently by combining the state-of-the-art research with the challenges from real-time applications. The benefits of such workshops by collaborating the researchers and tool vendors are, to develop the tools in a short period of time and to eliminate the redundant works by other researchers and tool vendors. The workshops on refactoring tools are being conducted annually at various places

The first workshop on refactoring tools was conducted on July 31st 2007 in conjunction with European Conference on Object-Oriented Programming (ECOOP) [https://netfiles.uiuc.edu/dig/RefactoringWorkshop/] at Berlin. Various papers like automated refactoring for improved cohesion, reuse based refactoring tools, Engineering reusability for software refactoring tools and others were presented and discussed. The proceedings of the first workshop can be found as a TU Berlin Technical Report, ISSN 1436-9915.

The second workshop on refactoring tools was conducted on October 19th 2008 in conjunction with Object-Oriented Programming Systems, Languages and Applications (OOPSLA) [https://netfiles.uiuc.edu/dig/RefactoringInfo/WRT08/] at Nashville, Tennessee. Various papers that were accepted and discussed were Cross Language Refactoring for Eclipse plug-ins, Tool support for refactoring functional programs, Towards a Refactoring guideline using code clone classification and others. More accepted papers at the second workshop can be found at [https://agora.cs.illinois.edu/display/wrt08/Accepted+Papers]. The interest in research in refactoring tools has increased to a greater extent that more papers were submitted and more researchers and tool vendors like JetBrains, Microsoft participated at the workshop.

The third workshop on refactoring tools is going to be held on October 25-29, 2009 in conjunction with Object-Oriented Programming Systems, Languages and Applications (OOPSLA) [https://netfiles.uiuc.edu/dig/RefactoringInfo/WRT09/] at Orlando, Florida. The papers have been invited for the topics which include language-independent transformation frameworks, language-independent analysis frameworks and analytical representations.

=== '''Ongoing Research''' ===

Refactoring in general preserves the behavior of the program during restructuring. But with the metaphor of extended language, the refactoring can be done in an efficient manner. The extended language implementation technique is all about embedding the source code into the extended language where the refactoring is easier to perform and then translating the refactored code into original language. This has been implemented on the well-known refactoring ‘Extract Method’ which showed the results that overall refactoring can be decomposed into micro-refactorings which are easy to implement and test.

Another improvement in which a tool can provide is the refactoring based on invariant preservation rather on the regular pre-condition based. The program invariants are nothing but the predicates about the objects state and their relationships which remain valid for every execution of program. There are quite a few initiatives that can be taken as part of the future research, which include the structural refactorings ‘Encapsulate Field’[http://sourcemaking.com/refactoring/encapsulate-field] or ‘Move Method’[http://www.refactoring.com/catalog/moveMethod.html] implementation using the micro-refactoring (refactorings which are used to perform small restructuring at once) decomposition approach. The above research is being conducted by the Programming Tools Group at University of Oxford.More information on this research can be found at [http://progtools.comlab.ox.ac.uk/projects/refactoring/ecoop09.pdf]

Lots of initiatives are being taken by tool vendors to improve refactoring tools. One such case is Net Beans where research is being carried on in this arena. The “replace method code duplicate” feature is being designed to locate selected method code repetitions and turn them in to a method call. The “generify” feature is currently developed for the transformation of non – generic code in to generic aware code. The “copy class” feature is currently in experimental stage to tap the feature of refactoring that allows to copy an existing class or interface. Likewise other features like “Inline method” which is used to inline a method, “Introduce variable” and “Clean up” are currently developed in their labs.

=== '''Survey On Refactoring Tools''' ===

In general,survey is one form of an initiative taken to improve any development environment.It includes complete analysis of an given environment and highlights various features like the current trend, future scope and limitations. All these helps in the potential development of efficient environment. Like wise survey have been done on refactoring tools which compares the refactoring tools support on various IDE's which includes Eclipse,Net Beans and IDEA. This survey gives an idea of which IDE supports the specific refactoring in an efficient manner. For more information about the findings please refer to "Refactoring Tools and Complementary Techniques"[http://www2.computer.org/portal/web/csdl/doi/10.1109/AICCSA.2006.205164]

=== '''Other Initiatives''' ===

Apart from workshops held specifically for refactoring tools, other conferences have been organized by Automated Software Engineering (ASE), International Conference on Software Engineering (ICSE), Foundations of Software Engineering (FSE) wherein papers on refactoring have been presented and awarded the best paper award.

In addition to the workshops and conferences, the weekly contest on refactoring “Refactor It! The Weekly Book Giveaway” has been started by Billy McCafferty to increase the awareness and interest among the software developers, students and other programming communities. Various groups like Software Architecture Group (SAG) at University of Illinois at Urbana-Champaign, Program Analysis and Transformation (PAT) group at IBM TJ Watson Research Center have been organized at Universities and Organizations to conduct research in refactoring tools and to improve the current generation of refactoring tools. More details about various groups and people can be found at [https://netfiles.uiuc.edu/dig/RefactoringInfo/people.html]

== External Links ==

Refactor It contest [http://devlicio.us/blogs/billy_mccafferty/archive/2006/11/13/refactor-it-the-weekly-book-giveaway.aspx]

Refactoring tool for .NET [http://submain.com/products/codeit.once.aspx]

=== '''Books''' ===

Refactoring Workbook - William.C.Wake [http://www.amazon.com/exec/obidos/tg/detail/-/0321109295]

Refactoring to Patterns - [http://industriallogic.com/xp/refactoring/]

Refactoring Databases : Evolutionary Database Design - [http://www.amazon.com/exec/obidos/ASIN/0321293533]

Professional Refactoring in Visual Basic - [http://www.amazon.com/gp/product/0470179791]

CoreJ2EE Patterns - [http://www.amazon.com/Core-J2EE-Patterns-Practices-Strategies/dp/0131422464]

== References ==

=== '''Thesis Works''' ===

William F. Opdyke, Refactoring object-oriented frameworks, University of Illinois at Urbana-Champaign, Champaign, IL, 1992 [http://portal.acm.org/citation.cfm?id=169783&dl=GUIDE&coll=GUIDE&CFID=50708246&CFTOKEN=47231553]

Refactoring as Formal Refinements- Marico Lopes Cornelio [http://dsc.upe.br/~mlc/PhDThesis/RefactoringsAsFormalRefinements.pdf]

Practical Analysis for Refactoring – Donald B Roberts, University of Illinois at Urbana-Champaign Champaign, IL, USA[http://portal.acm.org/citation.cfm?id=871251]

Refactoring Tools and Complementary Techniques - Martin Drozdz, Derrick G Kourie, Bruce W Watson, Andrew Boake Espresso Research Group, Department of Computer Science, University of Pretoria, Pretoria, South Africa 0001 [http://www2.computer.org/portal/web/csdl/doi/10.1109/AICCSA.2006.205164]

=== '''Other Papers/Conferences''' ===

William F. Opdyke and Ralph E. Johnson. Refactoring: An aid in designing application frameworks and evolving object-oriented systems. In Proceedings of Symposium on Object- Oriented Programming Emphasizing Practical Applications (SOOPPA), September 1990.

Refactoring, Reuse & Reality, Bill Opdyke, Lucent Technologies/ Bell Labs, Copyright 1999, Lucent Technologies[http://chip.cs.uiuc.edu/users/opdyke/wfo.990201.refac.html]

Why Don’t People Use Refactoring Tools? Emerson Murphy-Hill and Andrew P. Black, Portland State University [http://web.cecs.pdx.edu/~black/publications/WRT07.pdf?id=1176678&type=pdf&coll=&dl=acm&CFID=15151515&CFTOKEN=6184618]

First workshop on refactoring in conjunction with ecoop Berlin 07 [https://netfiles.uiuc.edu/dig/RefactoringWorkshop/]

Second ACM Workshop on Refactoring Tools (WRT'08)[https://netfiles.uiuc.edu/dig/RefactoringInfo/WRT08/]

Accepted papers for WRT’08 [https://agora.cs.illinois.edu/display/wrt08/Accepted+Papers]

Third ACM Workshop on Refactoring Tools (WRT'09)[https://netfiles.uiuc.edu/dig/RefactoringInfo/WRT09/]

ACM SIGSOFT 2006 / FSE 14[http://www.cs.uoregon.edu/fse-14/]

29th Int. Conference on Software Engineering® 20 - 26 May 2007[http://web4.cs.ucl.ac.uk/icse07/]

21st IEEE/ACM International Conference on Automated Software Engineering[http://ase.cs.uni-essen.de/ase/past/ase2006/]

=== '''Web''' ===

Refactoring Info[https://netfiles.uiuc.edu/dig/RefactoringInfo/index.html]

www.refactoring.com [http://www.refactoring.com/]

Refactoring at AllExperts [http://en.allexperts.com/e/r/re/refactoring.html]

Refactoring Tool - NetBeans [http://refactoring.netbeans.org/]

CSC/ECE 517 Fall 2009/wiki1a 9 DS

2009-09-16T02:52:08Z

Screenit: /* '''Survey On Refactoring Tools''' */

'''Refactoring Tools - Academic Underpinnings and Improvement Initiatives'''

----

== Definition ==

Refactoring[http://en.wikipedia.org/wiki/Code_refactoring] is defined as the technique by which the existing body of the code is restructured by changing the inner structure and preserving its external behavior. More common refactorings that are available can be found here [http://www.refactoring.com/catalog/index.html]. The tools which are used to achieve this purpose are commonly known as refactoring tools.

Refactoring tools are provided as Integrated Development Environment (IDE) features currently and are available for all popular programming languages. For instance, the common IDEs that provide the refactoring tools are IBM’s Eclipse, Sun’s Netbeans and IntelliJ’s IDEA.

Below is an example of refactoring "extract method"

Code Before refactoring

public class Refactoringjava {
public static void main(String args[]){
int a = 0,b =2,result;
result = a+b;
System.out.println("Sum =" + result);
}

Code after Refactoring

public class Refactoringjava {
public static void main(String args[]){
int a = 0,b =2,result;
result = sum(a,b);
System.out.println("Sum =" + result);
}
static int sum(int x,int y)
{
int sum = x+y;
return(sum);
}

== Overview ==
This deals with the academic underpinnings of refactoring starting from its evolution and the initiatives taken to improve the current generation of refactoring tools.In addition, this discusses the on going research initiatives to enhance the features in refactoring tools. It also throws lights up on various books, academic thesis, conferences and workshops on the topic of refactoring.

== Academic Underpinnings ==

=== '''Motivation''' ===

The first official thesis on the area of refactoring leads back to 1992 when Bill Opdyke finished his thesis on the topic "Refactoring Object-Oriented Frameworks"[http://portal.acm.org/citation.cfm?id=169783&dl=GUIDE&coll=GUIDE&CFID=50708246&CFTOKEN=47231553]. Bill Opdyke was working in Bell Laboratories developing electronic switching systems.
When he started to pursue his doctoral studies he wanted it to be related to practical business applications. That is when he narrowed down on this topic which led to the official shaping of the cloud refactoring.

The Basic motivation behind the emergence of refactoring was the software re-usability and cutting down cost involved in restructuring software for various purposes. Thus refactoring leads to software reuse in future.

Though it might appear that refactoring began in research labs it actually emerged on an ad-hoc basis when object-oriented programmers came across situations where they felt the need for change in object oriented software. Refactoring actually has its roots way back. Factoring was a key technique in Forth Language from its birth in 70’s. Absence of appropriate syntax made it not possible to extract the best use out of it. Ralph Johnson was the first person to use the name refactoring in print. Along with Bill Opdyke he published a paper on refactoring in 1990.

=== '''Etymology''' ===

The first known use of the term “refactoring” appeared in “Refactoring: An Aid in Designing Application Frameworks and Evolving Object-Oriented Systems” by Ralph Johnson and Bill Opdyke in 1990. But Refactoring as a function and as a technique, was almost certainly used before then.

=== '''More Works''' ===

Lot of work has been done on this area which includes the thesis work “Practical Analysis for refactoring” [http://portal.acm.org/citation.cfm?id=871251] by Donald Bradley Roberts. It focuses on several ways to make a refactoring tool that is both fast and reliable enough to be useful. In another thesis work “Refactoring as Formal Refinements” [http://dsc.upe.br/~mlc/PhDThesis/RefactoringsAsFormalRefinements.pdf] by Márcio Cornélio throws light on algebraic technique that presents refactoring as behavior preserving transformation. For list of other thesis works and papers refer to the References section.

=== '''Books on Refactoring''' ===

Various books are available on the topic of refactoring these days. The initial list of books includes “Refactoring: Improving the Design of Existing Code“ [http://www.amazon.com/exec/obidos/ASIN/0201485672] by Martin Flower and Refactoring to Patterns [http://www.industriallogic.com/xp/refactoring/] by Joshua Kerievsky and many more books on this topic. For listing of books on refactoring refer to the external links.

== Initiatives taken to improve current generation of refactoring tools ==

Various initiatives like conferences, workshops are conducted by Organizations like Institute of Electrical and Electronics Engineers (IEEE), Associate for Computing Machinery (ACM) to improve the current generation of refactoring tools. The first initiative taken to improve the current generation of refactoring tools was the creation of the refactoring research web portal ([http://refactoring.info]).
This research web portal includes a collection of links and articles that provide the researchers and industrial engineers an up-to-date knowledge on refactoring.

=== '''Workshops and Conferences''' ===

The second initiative taken was, organization of workshops which serve as a forum to bring researchers and tool vendors together for collaborative efforts in developing the refactoring tools. This initiative has been taken with the motive to develop the tool support for refactoring efficiently by combining the state-of-the-art research with the challenges from real-time applications. The benefits of such workshops by collaborating the researchers and tool vendors are, to develop the tools in a short period of time and to eliminate the redundant works by other researchers and tool vendors. The workshops on refactoring tools are being conducted annually at various places

The first workshop on refactoring tools was conducted on July 31st 2007 in conjunction with European Conference on Object-Oriented Programming (ECOOP) [https://netfiles.uiuc.edu/dig/RefactoringWorkshop/] at Berlin. Various papers like automated refactoring for improved cohesion, reuse based refactoring tools, Engineering reusability for software refactoring tools and others were presented and discussed. The proceedings of the first workshop can be found as a TU Berlin Technical Report, ISSN 1436-9915.

The second workshop on refactoring tools was conducted on October 19th 2008 in conjunction with Object-Oriented Programming Systems, Languages and Applications (OOPSLA) [https://netfiles.uiuc.edu/dig/RefactoringInfo/WRT08/] at Nashville, Tennessee. Various papers that were accepted and discussed were Cross Language Refactoring for Eclipse plug-ins, Tool support for refactoring functional programs, Towards a Refactoring guideline using code clone classification and others. More accepted papers at the second workshop can be found at [https://agora.cs.illinois.edu/display/wrt08/Accepted+Papers]. The interest in research in refactoring tools has increased to a greater extent that more papers were submitted and more researchers and tool vendors like JetBrains, Microsoft participated at the workshop.

The third workshop on refactoring tools is going to be held on October 25-29, 2009 in conjunction with Object-Oriented Programming Systems, Languages and Applications (OOPSLA) [https://netfiles.uiuc.edu/dig/RefactoringInfo/WRT09/] at Orlando, Florida. The papers have been invited for the topics which include language-independent transformation frameworks, language-independent analysis frameworks and analytical representations.

=== '''Ongoing Research''' ===

Refactoring in general preserves the behavior of the program during restructuring. But with the metaphor of extended language, the refactoring can be done in an efficient manner. The extended language implementation technique is all about embedding the source code into the extended language where the refactoring is easier to perform and then translating the refactored code into original language. This has been implemented on the well-known refactoring ‘Extract Method’ which showed the results that overall refactoring can be decomposed into micro-refactorings which are easy to implement and test.

Another improvement in which a tool can provide is the refactoring based on invariant preservation rather on the regular pre-condition based. The program invariants are nothing but the predicates about the objects state and their relationships which remain valid for every execution of program. There are quite a few initiatives that can be taken as part of the future research, which include the structural refactorings ‘Encapsulate Field’[http://sourcemaking.com/refactoring/encapsulate-field] or ‘Move Method’[http://www.refactoring.com/catalog/moveMethod.html] implementation using the micro-refactoring (refactorings which are used to perform small restructuring at once) decomposition approach. The above research is being conducted by the Programming Tools Group at University of Oxford.More information on this research can be found at [http://progtools.comlab.ox.ac.uk/projects/refactoring/ecoop09.pdf]

Lots of initiatives are being taken by tool vendors to improve refactoring tools. One such case is Net Beans where research is being carried on in this arena. The “replace method code duplicate” feature is being designed to locate selected method code repetitions and turn them in to a method call. The “generify” feature is currently developed for the transformation of non – generic code in to generic aware code. The “copy class” feature is currently in experimental stage to tap the feature of refactoring that allows to copy an existing class or interface. Likewise other features like “Inline method” which is used to inline a method, “Introduce variable” and “Clean up” are currently developed in their labs.

=== '''Survey On Refactoring Tools''' ===

In general,survey is one form of an initiative taken to improve any development environment.It includes complete analysis of an given environment and highlights various deliverable like the current trend, drawbacks and limitations. All these helps in the potential development of efficient environment. Like wise survey have been done on refactoring tools which compares the refactoring tools support on various IDE's which includes Eclipse,Net Beans and IDEA. This survey gives an idea of which IDE supports the specific refactoring in an efficient manner. For more information about the findings please refer to "Refactoring Tools and Complementary Techniques"[http://www2.computer.org/portal/web/csdl/doi/10.1109/AICCSA.2006.205164]

=== '''Other Initiatives''' ===

Apart from workshops held specifically for refactoring tools, other conferences have been organized by Automated Software Engineering (ASE), International Conference on Software Engineering (ICSE), Foundations of Software Engineering (FSE) wherein papers on refactoring have been presented and awarded the best paper award.

In addition to the workshops and conferences, the weekly contest on refactoring “Refactor It! The Weekly Book Giveaway” has been started by Billy McCafferty to increase the awareness and interest among the software developers, students and other programming communities. Various groups like Software Architecture Group (SAG) at University of Illinois at Urbana-Champaign, Program Analysis and Transformation (PAT) group at IBM TJ Watson Research Center have been organized at Universities and Organizations to conduct research in refactoring tools and to improve the current generation of refactoring tools. More details about various groups and people can be found at [https://netfiles.uiuc.edu/dig/RefactoringInfo/people.html]

== External Links ==

Refactor It contest [http://devlicio.us/blogs/billy_mccafferty/archive/2006/11/13/refactor-it-the-weekly-book-giveaway.aspx]

Refactoring tool for .NET [http://submain.com/products/codeit.once.aspx]

=== '''Books''' ===

Refactoring Workbook - William.C.Wake [http://www.amazon.com/exec/obidos/tg/detail/-/0321109295]

Refactoring to Patterns - [http://industriallogic.com/xp/refactoring/]

Refactoring Databases : Evolutionary Database Design - [http://www.amazon.com/exec/obidos/ASIN/0321293533]

Professional Refactoring in Visual Basic - [http://www.amazon.com/gp/product/0470179791]

CoreJ2EE Patterns - [http://www.amazon.com/Core-J2EE-Patterns-Practices-Strategies/dp/0131422464]

== References ==

=== '''Thesis Works''' ===

William F. Opdyke, Refactoring object-oriented frameworks, University of Illinois at Urbana-Champaign, Champaign, IL, 1992 [http://portal.acm.org/citation.cfm?id=169783&dl=GUIDE&coll=GUIDE&CFID=50708246&CFTOKEN=47231553]

Refactoring as Formal Refinements- Marico Lopes Cornelio [http://dsc.upe.br/~mlc/PhDThesis/RefactoringsAsFormalRefinements.pdf]

Practical Analysis for Refactoring – Donald B Roberts, University of Illinois at Urbana-Champaign Champaign, IL, USA[http://portal.acm.org/citation.cfm?id=871251]

Refactoring Tools and Complementary Techniques - Martin Drozdz, Derrick G Kourie, Bruce W Watson, Andrew Boake Espresso Research Group, Department of Computer Science, University of Pretoria, Pretoria, South Africa 0001 [http://www2.computer.org/portal/web/csdl/doi/10.1109/AICCSA.2006.205164]

=== '''Other Papers/Conferences''' ===

William F. Opdyke and Ralph E. Johnson. Refactoring: An aid in designing application frameworks and evolving object-oriented systems. In Proceedings of Symposium on Object- Oriented Programming Emphasizing Practical Applications (SOOPPA), September 1990.

Refactoring, Reuse & Reality, Bill Opdyke, Lucent Technologies/ Bell Labs, Copyright 1999, Lucent Technologies[http://chip.cs.uiuc.edu/users/opdyke/wfo.990201.refac.html]

Why Don’t People Use Refactoring Tools? Emerson Murphy-Hill and Andrew P. Black, Portland State University [http://web.cecs.pdx.edu/~black/publications/WRT07.pdf?id=1176678&type=pdf&coll=&dl=acm&CFID=15151515&CFTOKEN=6184618]

First workshop on refactoring in conjunction with ecoop Berlin 07 [https://netfiles.uiuc.edu/dig/RefactoringWorkshop/]

Second ACM Workshop on Refactoring Tools (WRT'08)[https://netfiles.uiuc.edu/dig/RefactoringInfo/WRT08/]

Accepted papers for WRT’08 [https://agora.cs.illinois.edu/display/wrt08/Accepted+Papers]

Third ACM Workshop on Refactoring Tools (WRT'09)[https://netfiles.uiuc.edu/dig/RefactoringInfo/WRT09/]

ACM SIGSOFT 2006 / FSE 14[http://www.cs.uoregon.edu/fse-14/]

29th Int. Conference on Software Engineering® 20 - 26 May 2007[http://web4.cs.ucl.ac.uk/icse07/]

21st IEEE/ACM International Conference on Automated Software Engineering[http://ase.cs.uni-essen.de/ase/past/ase2006/]

=== '''Web''' ===

Refactoring Info[https://netfiles.uiuc.edu/dig/RefactoringInfo/index.html]

www.refactoring.com [http://www.refactoring.com/]

Refactoring at AllExperts [http://en.allexperts.com/e/r/re/refactoring.html]

Refactoring Tool - NetBeans [http://refactoring.netbeans.org/]

CSC/ECE 517 Fall 2009/wiki1a 9 DS

2009-09-16T02:51:51Z

Screenit: /* '''Survey On Refactoring Tools''' */

'''Refactoring Tools - Academic Underpinnings and Improvement Initiatives'''

----

== Definition ==

Refactoring[http://en.wikipedia.org/wiki/Code_refactoring] is defined as the technique by which the existing body of the code is restructured by changing the inner structure and preserving its external behavior. More common refactorings that are available can be found here [http://www.refactoring.com/catalog/index.html]. The tools which are used to achieve this purpose are commonly known as refactoring tools.

Refactoring tools are provided as Integrated Development Environment (IDE) features currently and are available for all popular programming languages. For instance, the common IDEs that provide the refactoring tools are IBM’s Eclipse, Sun’s Netbeans and IntelliJ’s IDEA.

Below is an example of refactoring "extract method"

Code Before refactoring

public class Refactoringjava {
public static void main(String args[]){
int a = 0,b =2,result;
result = a+b;
System.out.println("Sum =" + result);
}

Code after Refactoring

public class Refactoringjava {
public static void main(String args[]){
int a = 0,b =2,result;
result = sum(a,b);
System.out.println("Sum =" + result);
}
static int sum(int x,int y)
{
int sum = x+y;
return(sum);
}

== Overview ==
This deals with the academic underpinnings of refactoring starting from its evolution and the initiatives taken to improve the current generation of refactoring tools.In addition, this discusses the on going research initiatives to enhance the features in refactoring tools. It also throws lights up on various books, academic thesis, conferences and workshops on the topic of refactoring.

== Academic Underpinnings ==

=== '''Motivation''' ===

The first official thesis on the area of refactoring leads back to 1992 when Bill Opdyke finished his thesis on the topic "Refactoring Object-Oriented Frameworks"[http://portal.acm.org/citation.cfm?id=169783&dl=GUIDE&coll=GUIDE&CFID=50708246&CFTOKEN=47231553]. Bill Opdyke was working in Bell Laboratories developing electronic switching systems.
When he started to pursue his doctoral studies he wanted it to be related to practical business applications. That is when he narrowed down on this topic which led to the official shaping of the cloud refactoring.

The Basic motivation behind the emergence of refactoring was the software re-usability and cutting down cost involved in restructuring software for various purposes. Thus refactoring leads to software reuse in future.

Though it might appear that refactoring began in research labs it actually emerged on an ad-hoc basis when object-oriented programmers came across situations where they felt the need for change in object oriented software. Refactoring actually has its roots way back. Factoring was a key technique in Forth Language from its birth in 70’s. Absence of appropriate syntax made it not possible to extract the best use out of it. Ralph Johnson was the first person to use the name refactoring in print. Along with Bill Opdyke he published a paper on refactoring in 1990.

=== '''Etymology''' ===

The first known use of the term “refactoring” appeared in “Refactoring: An Aid in Designing Application Frameworks and Evolving Object-Oriented Systems” by Ralph Johnson and Bill Opdyke in 1990. But Refactoring as a function and as a technique, was almost certainly used before then.

=== '''More Works''' ===

Lot of work has been done on this area which includes the thesis work “Practical Analysis for refactoring” [http://portal.acm.org/citation.cfm?id=871251] by Donald Bradley Roberts. It focuses on several ways to make a refactoring tool that is both fast and reliable enough to be useful. In another thesis work “Refactoring as Formal Refinements” [http://dsc.upe.br/~mlc/PhDThesis/RefactoringsAsFormalRefinements.pdf] by Márcio Cornélio throws light on algebraic technique that presents refactoring as behavior preserving transformation. For list of other thesis works and papers refer to the References section.

=== '''Books on Refactoring''' ===

Various books are available on the topic of refactoring these days. The initial list of books includes “Refactoring: Improving the Design of Existing Code“ [http://www.amazon.com/exec/obidos/ASIN/0201485672] by Martin Flower and Refactoring to Patterns [http://www.industriallogic.com/xp/refactoring/] by Joshua Kerievsky and many more books on this topic. For listing of books on refactoring refer to the external links.

== Initiatives taken to improve current generation of refactoring tools ==

Various initiatives like conferences, workshops are conducted by Organizations like Institute of Electrical and Electronics Engineers (IEEE), Associate for Computing Machinery (ACM) to improve the current generation of refactoring tools. The first initiative taken to improve the current generation of refactoring tools was the creation of the refactoring research web portal ([http://refactoring.info]).
This research web portal includes a collection of links and articles that provide the researchers and industrial engineers an up-to-date knowledge on refactoring.

=== '''Workshops and Conferences''' ===

The second initiative taken was, organization of workshops which serve as a forum to bring researchers and tool vendors together for collaborative efforts in developing the refactoring tools. This initiative has been taken with the motive to develop the tool support for refactoring efficiently by combining the state-of-the-art research with the challenges from real-time applications. The benefits of such workshops by collaborating the researchers and tool vendors are, to develop the tools in a short period of time and to eliminate the redundant works by other researchers and tool vendors. The workshops on refactoring tools are being conducted annually at various places

The first workshop on refactoring tools was conducted on July 31st 2007 in conjunction with European Conference on Object-Oriented Programming (ECOOP) [https://netfiles.uiuc.edu/dig/RefactoringWorkshop/] at Berlin. Various papers like automated refactoring for improved cohesion, reuse based refactoring tools, Engineering reusability for software refactoring tools and others were presented and discussed. The proceedings of the first workshop can be found as a TU Berlin Technical Report, ISSN 1436-9915.

The second workshop on refactoring tools was conducted on October 19th 2008 in conjunction with Object-Oriented Programming Systems, Languages and Applications (OOPSLA) [https://netfiles.uiuc.edu/dig/RefactoringInfo/WRT08/] at Nashville, Tennessee. Various papers that were accepted and discussed were Cross Language Refactoring for Eclipse plug-ins, Tool support for refactoring functional programs, Towards a Refactoring guideline using code clone classification and others. More accepted papers at the second workshop can be found at [https://agora.cs.illinois.edu/display/wrt08/Accepted+Papers]. The interest in research in refactoring tools has increased to a greater extent that more papers were submitted and more researchers and tool vendors like JetBrains, Microsoft participated at the workshop.

The third workshop on refactoring tools is going to be held on October 25-29, 2009 in conjunction with Object-Oriented Programming Systems, Languages and Applications (OOPSLA) [https://netfiles.uiuc.edu/dig/RefactoringInfo/WRT09/] at Orlando, Florida. The papers have been invited for the topics which include language-independent transformation frameworks, language-independent analysis frameworks and analytical representations.

=== '''Ongoing Research''' ===

Refactoring in general preserves the behavior of the program during restructuring. But with the metaphor of extended language, the refactoring can be done in an efficient manner. The extended language implementation technique is all about embedding the source code into the extended language where the refactoring is easier to perform and then translating the refactored code into original language. This has been implemented on the well-known refactoring ‘Extract Method’ which showed the results that overall refactoring can be decomposed into micro-refactorings which are easy to implement and test.

Another improvement in which a tool can provide is the refactoring based on invariant preservation rather on the regular pre-condition based. The program invariants are nothing but the predicates about the objects state and their relationships which remain valid for every execution of program. There are quite a few initiatives that can be taken as part of the future research, which include the structural refactorings ‘Encapsulate Field’[http://sourcemaking.com/refactoring/encapsulate-field] or ‘Move Method’[http://www.refactoring.com/catalog/moveMethod.html] implementation using the micro-refactoring (refactorings which are used to perform small restructuring at once) decomposition approach. The above research is being conducted by the Programming Tools Group at University of Oxford.More information on this research can be found at [http://progtools.comlab.ox.ac.uk/projects/refactoring/ecoop09.pdf]

Lots of initiatives are being taken by tool vendors to improve refactoring tools. One such case is Net Beans where research is being carried on in this arena. The “replace method code duplicate” feature is being designed to locate selected method code repetitions and turn them in to a method call. The “generify” feature is currently developed for the transformation of non – generic code in to generic aware code. The “copy class” feature is currently in experimental stage to tap the feature of refactoring that allows to copy an existing class or interface. Likewise other features like “Inline method” which is used to inline a method, “Introduce variable” and “Clean up” are currently developed in their labs.

=== '''Survey On Refactoring Tools''' ===

In general,survey is one form of an initiative taken to improve any development environment.It includes complete analysis of an given environment and highlights various deliverable like the current trend, drawbacks and limitations. All these helps in the potential development of efficient environment. Like wise survey have been done on refactoring tools which compares the refactoring tools support on various IDE's which includes Eclipse,Net Beans and IDEA. This survey gives an idea of which IDE supports the specific refactoring in an efficient manner. For more information about the findings please refer to "Refactoring Tools and Complementary Techniques"[http://www2.computer.org/portal/web/csdl/doi/10.1109/AICCSA.2006.205164]

=== '''Other Initiatives''' ===

Apart from workshops held specifically for refactoring tools, other conferences have been organized by Automated Software Engineering (ASE), International Conference on Software Engineering (ICSE), Foundations of Software Engineering (FSE) wherein papers on refactoring have been presented and awarded the best paper award.

In addition to the workshops and conferences, the weekly contest on refactoring “Refactor It! The Weekly Book Giveaway” has been started by Billy McCafferty to increase the awareness and interest among the software developers, students and other programming communities. Various groups like Software Architecture Group (SAG) at University of Illinois at Urbana-Champaign, Program Analysis and Transformation (PAT) group at IBM TJ Watson Research Center have been organized at Universities and Organizations to conduct research in refactoring tools and to improve the current generation of refactoring tools. More details about various groups and people can be found at [https://netfiles.uiuc.edu/dig/RefactoringInfo/people.html]

== External Links ==

Refactor It contest [http://devlicio.us/blogs/billy_mccafferty/archive/2006/11/13/refactor-it-the-weekly-book-giveaway.aspx]

Refactoring tool for .NET [http://submain.com/products/codeit.once.aspx]

=== '''Books''' ===

Refactoring Workbook - William.C.Wake [http://www.amazon.com/exec/obidos/tg/detail/-/0321109295]

Refactoring to Patterns - [http://industriallogic.com/xp/refactoring/]

Refactoring Databases : Evolutionary Database Design - [http://www.amazon.com/exec/obidos/ASIN/0321293533]

Professional Refactoring in Visual Basic - [http://www.amazon.com/gp/product/0470179791]

CoreJ2EE Patterns - [http://www.amazon.com/Core-J2EE-Patterns-Practices-Strategies/dp/0131422464]

== References ==

=== '''Thesis Works''' ===

William F. Opdyke, Refactoring object-oriented frameworks, University of Illinois at Urbana-Champaign, Champaign, IL, 1992 [http://portal.acm.org/citation.cfm?id=169783&dl=GUIDE&coll=GUIDE&CFID=50708246&CFTOKEN=47231553]

Refactoring as Formal Refinements- Marico Lopes Cornelio [http://dsc.upe.br/~mlc/PhDThesis/RefactoringsAsFormalRefinements.pdf]

Practical Analysis for Refactoring – Donald B Roberts, University of Illinois at Urbana-Champaign Champaign, IL, USA[http://portal.acm.org/citation.cfm?id=871251]

Refactoring Tools and Complementary Techniques - Martin Drozdz, Derrick G Kourie, Bruce W Watson, Andrew Boake Espresso Research Group, Department of Computer Science, University of Pretoria, Pretoria, South Africa 0001 [http://www2.computer.org/portal/web/csdl/doi/10.1109/AICCSA.2006.205164]

=== '''Other Papers/Conferences''' ===

William F. Opdyke and Ralph E. Johnson. Refactoring: An aid in designing application frameworks and evolving object-oriented systems. In Proceedings of Symposium on Object- Oriented Programming Emphasizing Practical Applications (SOOPPA), September 1990.

Refactoring, Reuse & Reality, Bill Opdyke, Lucent Technologies/ Bell Labs, Copyright 1999, Lucent Technologies[http://chip.cs.uiuc.edu/users/opdyke/wfo.990201.refac.html]

Why Don’t People Use Refactoring Tools? Emerson Murphy-Hill and Andrew P. Black, Portland State University [http://web.cecs.pdx.edu/~black/publications/WRT07.pdf?id=1176678&type=pdf&coll=&dl=acm&CFID=15151515&CFTOKEN=6184618]

First workshop on refactoring in conjunction with ecoop Berlin 07 [https://netfiles.uiuc.edu/dig/RefactoringWorkshop/]

Second ACM Workshop on Refactoring Tools (WRT'08)[https://netfiles.uiuc.edu/dig/RefactoringInfo/WRT08/]

Accepted papers for WRT’08 [https://agora.cs.illinois.edu/display/wrt08/Accepted+Papers]

Third ACM Workshop on Refactoring Tools (WRT'09)[https://netfiles.uiuc.edu/dig/RefactoringInfo/WRT09/]

ACM SIGSOFT 2006 / FSE 14[http://www.cs.uoregon.edu/fse-14/]

29th Int. Conference on Software Engineering® 20 - 26 May 2007[http://web4.cs.ucl.ac.uk/icse07/]

21st IEEE/ACM International Conference on Automated Software Engineering[http://ase.cs.uni-essen.de/ase/past/ase2006/]

=== '''Web''' ===

Refactoring Info[https://netfiles.uiuc.edu/dig/RefactoringInfo/index.html]

www.refactoring.com [http://www.refactoring.com/]

Refactoring at AllExperts [http://en.allexperts.com/e/r/re/refactoring.html]

Refactoring Tool - NetBeans [http://refactoring.netbeans.org/]

CSC/ECE 517 Fall 2009/wiki1a 9 DS

2009-09-16T02:38:18Z

Screenit:

'''Refactoring Tools - Academic Underpinnings and Improvement Initiatives'''

----

== Definition ==

Refactoring[http://en.wikipedia.org/wiki/Code_refactoring] is defined as the technique by which the existing body of the code is restructured by changing the inner structure and preserving its external behavior. More common refactorings that are available can be found here [http://www.refactoring.com/catalog/index.html]. The tools which are used to achieve this purpose are commonly known as refactoring tools.

Refactoring tools are provided as Integrated Development Environment (IDE) features currently and are available for all popular programming languages. For instance, the common IDEs that provide the refactoring tools are IBM’s Eclipse, Sun’s Netbeans and IntelliJ’s IDEA.

Below is an example of refactoring "extract method"

Code Before refactoring

public class Refactoringjava {
public static void main(String args[]){
int a = 0,b =2,result;
result = a+b;
System.out.println("Sum =" + result);
}

Code after Refactoring

public class Refactoringjava {
public static void main(String args[]){
int a = 0,b =2,result;
result = sum(a,b);
System.out.println("Sum =" + result);
}
static int sum(int x,int y)
{
int sum = x+y;
return(sum);
}

== Overview ==
This deals with the academic underpinnings of refactoring starting from its evolution and the initiatives taken to improve the current generation of refactoring tools.In addition, this discusses the on going research initiatives to enhance the features in refactoring tools. It also throws lights up on various books, academic thesis, conferences and workshops on the topic of refactoring.

== Academic Underpinnings ==

=== '''Motivation''' ===

The first official thesis on the area of refactoring leads back to 1992 when Bill Opdyke finished his thesis on the topic "Refactoring Object-Oriented Frameworks"[http://portal.acm.org/citation.cfm?id=169783&dl=GUIDE&coll=GUIDE&CFID=50708246&CFTOKEN=47231553]. Bill Opdyke was working in Bell Laboratories developing electronic switching systems.
When he started to pursue his doctoral studies he wanted it to be related to practical business applications. That is when he narrowed down on this topic which led to the official shaping of the cloud refactoring.

The Basic motivation behind the emergence of refactoring was the software re-usability and cutting down cost involved in restructuring software for various purposes. Thus refactoring leads to software reuse in future.

Though it might appear that refactoring began in research labs it actually emerged on an ad-hoc basis when object-oriented programmers came across situations where they felt the need for change in object oriented software. Refactoring actually has its roots way back. Factoring was a key technique in Forth Language from its birth in 70’s. Absence of appropriate syntax made it not possible to extract the best use out of it. Ralph Johnson was the first person to use the name refactoring in print. Along with Bill Opdyke he published a paper on refactoring in 1990.

=== '''Etymology''' ===

The first known use of the term “refactoring” appeared in “Refactoring: An Aid in Designing Application Frameworks and Evolving Object-Oriented Systems” by Ralph Johnson and Bill Opdyke in 1990. But Refactoring as a function and as a technique, was almost certainly used before then.

=== '''More Works''' ===

Lot of work has been done on this area which includes the thesis work “Practical Analysis for refactoring” [http://portal.acm.org/citation.cfm?id=871251] by Donald Bradley Roberts. It focuses on several ways to make a refactoring tool that is both fast and reliable enough to be useful. In another thesis work “Refactoring as Formal Refinements” [http://dsc.upe.br/~mlc/PhDThesis/RefactoringsAsFormalRefinements.pdf] by Márcio Cornélio throws light on algebraic technique that presents refactoring as behavior preserving transformation. For list of other thesis works and papers refer to the References section.

=== '''Books on Refactoring''' ===

Various books are available on the topic of refactoring these days. The initial list of books includes “Refactoring: Improving the Design of Existing Code“ [http://www.amazon.com/exec/obidos/ASIN/0201485672] by Martin Flower and Refactoring to Patterns [http://www.industriallogic.com/xp/refactoring/] by Joshua Kerievsky and many more books on this topic. For listing of books on refactoring refer to the external links.

== Initiatives taken to improve current generation of refactoring tools ==

Various initiatives like conferences, workshops are conducted by Organizations like Institute of Electrical and Electronics Engineers (IEEE), Associate for Computing Machinery (ACM) to improve the current generation of refactoring tools. The first initiative taken to improve the current generation of refactoring tools was the creation of the refactoring research web portal ([http://refactoring.info]).
This research web portal includes a collection of links and articles that provide the researchers and industrial engineers an up-to-date knowledge on refactoring.

=== '''Workshops and Conferences''' ===

The second initiative taken was, organization of workshops which serve as a forum to bring researchers and tool vendors together for collaborative efforts in developing the refactoring tools. This initiative has been taken with the motive to develop the tool support for refactoring efficiently by combining the state-of-the-art research with the challenges from real-time applications. The benefits of such workshops by collaborating the researchers and tool vendors are, to develop the tools in a short period of time and to eliminate the redundant works by other researchers and tool vendors. The workshops on refactoring tools are being conducted annually at various places

The first workshop on refactoring tools was conducted on July 31st 2007 in conjunction with European Conference on Object-Oriented Programming (ECOOP) [https://netfiles.uiuc.edu/dig/RefactoringWorkshop/] at Berlin. Various papers like automated refactoring for improved cohesion, reuse based refactoring tools, Engineering reusability for software refactoring tools and others were presented and discussed. The proceedings of the first workshop can be found as a TU Berlin Technical Report, ISSN 1436-9915.

The second workshop on refactoring tools was conducted on October 19th 2008 in conjunction with Object-Oriented Programming Systems, Languages and Applications (OOPSLA) [https://netfiles.uiuc.edu/dig/RefactoringInfo/WRT08/] at Nashville, Tennessee. Various papers that were accepted and discussed were Cross Language Refactoring for Eclipse plug-ins, Tool support for refactoring functional programs, Towards a Refactoring guideline using code clone classification and others. More accepted papers at the second workshop can be found at [https://agora.cs.illinois.edu/display/wrt08/Accepted+Papers]. The interest in research in refactoring tools has increased to a greater extent that more papers were submitted and more researchers and tool vendors like JetBrains, Microsoft participated at the workshop.

The third workshop on refactoring tools is going to be held on October 25-29, 2009 in conjunction with Object-Oriented Programming Systems, Languages and Applications (OOPSLA) [https://netfiles.uiuc.edu/dig/RefactoringInfo/WRT09/] at Orlando, Florida. The papers have been invited for the topics which include language-independent transformation frameworks, language-independent analysis frameworks and analytical representations.

=== '''Ongoing Research''' ===

Refactoring in general preserves the behavior of the program during restructuring. But with the metaphor of extended language, the refactoring can be done in an efficient manner. The extended language implementation technique is all about embedding the source code into the extended language where the refactoring is easier to perform and then translating the refactored code into original language. This has been implemented on the well-known refactoring ‘Extract Method’ which showed the results that overall refactoring can be decomposed into micro-refactorings which are easy to implement and test.

Another improvement in which a tool can provide is the refactoring based on invariant preservation rather on the regular pre-condition based. The program invariants are nothing but the predicates about the objects state and their relationships which remain valid for every execution of program. There are quite a few initiatives that can be taken as part of the future research, which include the structural refactorings ‘Encapsulate Field’[http://sourcemaking.com/refactoring/encapsulate-field] or ‘Move Method’[http://www.refactoring.com/catalog/moveMethod.html] implementation using the micro-refactoring (refactorings which are used to perform small restructuring at once) decomposition approach. The above research is being conducted by the Programming Tools Group at University of Oxford.More information on this research can be found at [http://progtools.comlab.ox.ac.uk/projects/refactoring/ecoop09.pdf]

Lots of initiatives are being taken by tool vendors to improve refactoring tools. One such case is Net Beans where research is being carried on in this arena. The “replace method code duplicate” feature is being designed to locate selected method code repetitions and turn them in to a method call. The “generify” feature is currently developed for the transformation of non – generic code in to generic aware code. The “copy class” feature is currently in experimental stage to tap the feature of refactoring that allows to copy an existing class or interface. Likewise other features like “Inline method” which is used to inline a method, “Introduce variable” and “Clean up” are currently developed in their labs.

=== '''Survey On Refactoring Tools''' ===

=== '''Other Initiatives''' ===

Apart from workshops held specifically for refactoring tools, other conferences have been organized by Automated Software Engineering (ASE), International Conference on Software Engineering (ICSE), Foundations of Software Engineering (FSE) wherein papers on refactoring have been presented and awarded the best paper award.

In addition to the workshops and conferences, the weekly contest on refactoring “Refactor It! The Weekly Book Giveaway” has been started by Billy McCafferty to increase the awareness and interest among the software developers, students and other programming communities. Various groups like Software Architecture Group (SAG) at University of Illinois at Urbana-Champaign, Program Analysis and Transformation (PAT) group at IBM TJ Watson Research Center have been organized at Universities and Organizations to conduct research in refactoring tools and to improve the current generation of refactoring tools. More details about various groups and people can be found at [https://netfiles.uiuc.edu/dig/RefactoringInfo/people.html]

== External Links ==

Refactor It contest [http://devlicio.us/blogs/billy_mccafferty/archive/2006/11/13/refactor-it-the-weekly-book-giveaway.aspx]

Refactoring tool for .NET [http://submain.com/products/codeit.once.aspx]

=== '''Books''' ===

Refactoring Workbook - William.C.Wake [http://www.amazon.com/exec/obidos/tg/detail/-/0321109295]

Refactoring to Patterns - [http://industriallogic.com/xp/refactoring/]

Refactoring Databases : Evolutionary Database Design - [http://www.amazon.com/exec/obidos/ASIN/0321293533]

Professional Refactoring in Visual Basic - [http://www.amazon.com/gp/product/0470179791]

CoreJ2EE Patterns - [http://www.amazon.com/Core-J2EE-Patterns-Practices-Strategies/dp/0131422464]

== References ==

=== '''Thesis Works''' ===

William F. Opdyke, Refactoring object-oriented frameworks, University of Illinois at Urbana-Champaign, Champaign, IL, 1992 [http://portal.acm.org/citation.cfm?id=169783&dl=GUIDE&coll=GUIDE&CFID=50708246&CFTOKEN=47231553]

Refactoring as Formal Refinements- Marico Lopes Cornelio [http://dsc.upe.br/~mlc/PhDThesis/RefactoringsAsFormalRefinements.pdf]

Practical Analysis for Refactoring – Donald B Roberts, University of Illinois at Urbana-Champaign Champaign, IL, USA[http://portal.acm.org/citation.cfm?id=871251]

Refactoring Tools and Complementary Techniques - Martin Drozdz, Derrick G Kourie, Bruce W Watson, Andrew Boake Espresso Research Group, Department of Computer Science, University of Pretoria, Pretoria, South Africa 0001 [http://www2.computer.org/portal/web/csdl/doi/10.1109/AICCSA.2006.205164]

=== '''Other Papers/Conferences''' ===

William F. Opdyke and Ralph E. Johnson. Refactoring: An aid in designing application frameworks and evolving object-oriented systems. In Proceedings of Symposium on Object- Oriented Programming Emphasizing Practical Applications (SOOPPA), September 1990.

Refactoring, Reuse & Reality, Bill Opdyke, Lucent Technologies/ Bell Labs, Copyright 1999, Lucent Technologies[http://chip.cs.uiuc.edu/users/opdyke/wfo.990201.refac.html]

Why Don’t People Use Refactoring Tools? Emerson Murphy-Hill and Andrew P. Black, Portland State University [http://web.cecs.pdx.edu/~black/publications/WRT07.pdf?id=1176678&type=pdf&coll=&dl=acm&CFID=15151515&CFTOKEN=6184618]

First workshop on refactoring in conjunction with ecoop Berlin 07 [https://netfiles.uiuc.edu/dig/RefactoringWorkshop/]

Second ACM Workshop on Refactoring Tools (WRT'08)[https://netfiles.uiuc.edu/dig/RefactoringInfo/WRT08/]

Accepted papers for WRT’08 [https://agora.cs.illinois.edu/display/wrt08/Accepted+Papers]

Third ACM Workshop on Refactoring Tools (WRT'09)[https://netfiles.uiuc.edu/dig/RefactoringInfo/WRT09/]

ACM SIGSOFT 2006 / FSE 14[http://www.cs.uoregon.edu/fse-14/]

29th Int. Conference on Software Engineering® 20 - 26 May 2007[http://web4.cs.ucl.ac.uk/icse07/]

21st IEEE/ACM International Conference on Automated Software Engineering[http://ase.cs.uni-essen.de/ase/past/ase2006/]

=== '''Web''' ===

Refactoring Info[https://netfiles.uiuc.edu/dig/RefactoringInfo/index.html]

www.refactoring.com [http://www.refactoring.com/]

Refactoring at AllExperts [http://en.allexperts.com/e/r/re/refactoring.html]

Refactoring Tool - NetBeans [http://refactoring.netbeans.org/]

CSC/ECE 517 Fall 2009/wiki1a 9 DS

2009-09-16T02:35:45Z

Screenit:

'''Refactoring Tools - Academic Underpinnings and Improvement Initiatives'''

----

== Definition ==

Refactoring[http://en.wikipedia.org/wiki/Code_refactoring] is defined as the technique by which the existing body of the code is restructured by changing the inner structure and preserving its external behavior. More common refactorings that are available can be found here [http://www.refactoring.com/catalog/index.html]. The tools which are used to achieve this purpose are commonly known as refactoring tools.

Refactoring tools are provided as Integrated Development Environment (IDE) features currently and are available for all popular programming languages. For instance, the common IDEs that provide the refactoring tools are IBM’s Eclipse, Sun’s Netbeans and IntelliJ’s IDEA.

Below is an example of refactoring "extract method"

Code Before refactoring

public class Refactoringjava {
public static void main(String args[]){
int a = 0,b =2,result;
result = a+b;
System.out.println("Sum =" + result);
}

Code after Refactoring

public class Refactoringjava {
public static void main(String args[]){
int a = 0,b =2,result;
result = sum(a,b);
System.out.println("Sum =" + result);
}
static int sum(int x,int y)
{
int sum = x+y;
return(sum);
}

== Overview ==
This deals with the academic underpinnings of refactoring starting from its evolution and the initiatives taken to improve the current generation of refactoring tools.In addition, this discusses the on going research initiatives to enhance the features in refactoring tools. It also throws lights up on various books, academic thesis, conferences and workshops on the topic of refactoring.

== Academic Underpinnings ==

=== '''Motivation''' ===

The first official thesis on the area of refactoring leads back to 1992 when Bill Opdyke finished his thesis on the topic "Refactoring Object-Oriented Frameworks"[http://portal.acm.org/citation.cfm?id=169783&dl=GUIDE&coll=GUIDE&CFID=50708246&CFTOKEN=47231553]. Bill Opdyke was working in Bell Laboratories developing electronic switching systems.
When he started to pursue his doctoral studies he wanted it to be related to practical business applications. That is when he narrowed down on this topic which led to the official shaping of the cloud refactoring.

The Basic motivation behind the emergence of refactoring was the software re-usability and cutting down cost involved in restructuring software for various purposes. Thus refactoring leads to software reuse in future.

Though it might appear that refactoring began in research labs it actually emerged on an ad-hoc basis when object-oriented programmers came across situations where they felt the need for change in object oriented software. Refactoring actually has its roots way back. Factoring was a key technique in Forth Language from its birth in 70’s. Absence of appropriate syntax made it not possible to extract the best use out of it. Ralph Johnson was the first person to use the name refactoring in print. Along with Bill Opdyke he published a paper on refactoring in 1990.

=== '''Etymology''' ===

The first known use of the term “refactoring” appeared in “Refactoring: An Aid in Designing Application Frameworks and Evolving Object-Oriented Systems” by Ralph Johnson and Bill Opdyke in 1990. But Refactoring as a function and as a technique, was almost certainly used before then.

=== '''More Works''' ===

Lot of work has been done on this area which includes the thesis work “Practical Analysis for refactoring” [http://portal.acm.org/citation.cfm?id=871251] by Donald Bradley Roberts. It focuses on several ways to make a refactoring tool that is both fast and reliable enough to be useful. In another thesis work “Refactoring as Formal Refinements” [http://dsc.upe.br/~mlc/PhDThesis/RefactoringsAsFormalRefinements.pdf] by Márcio Cornélio throws light on algebraic technique that presents refactoring as behavior preserving transformation. For list of other thesis works and papers refer to the References section.

=== '''Books on Refactoring''' ===

Various books are available on the topic of refactoring these days. The initial list of books includes “Refactoring: Improving the Design of Existing Code“ [http://www.amazon.com/exec/obidos/ASIN/0201485672] by Martin Flower and Refactoring to Patterns [http://www.industriallogic.com/xp/refactoring/] by Joshua Kerievsky and many more books on this topic. For listing of books on refactoring refer to the external links.

== Initiatives taken to improve current generation of refactoring tools ==

Various initiatives like conferences, workshops are conducted by Organizations like Institute of Electrical and Electronics Engineers (IEEE), Associate for Computing Machinery (ACM) to improve the current generation of refactoring tools. The first initiative taken to improve the current generation of refactoring tools was the creation of the refactoring research web portal ([http://refactoring.info]).
This research web portal includes a collection of links and articles that provide the researchers and industrial engineers an up-to-date knowledge on refactoring.

=== '''Workshops and Conferences''' ===

The second initiative taken was, organization of workshops which serve as a forum to bring researchers and tool vendors together for collaborative efforts in developing the refactoring tools. This initiative has been taken with the motive to develop the tool support for refactoring efficiently by combining the state-of-the-art research with the challenges from real-time applications. The benefits of such workshops by collaborating the researchers and tool vendors are, to develop the tools in a short period of time and to eliminate the redundant works by other researchers and tool vendors. The workshops on refactoring tools are being conducted annually at various places

The first workshop on refactoring tools was conducted on July 31st 2007 in conjunction with European Conference on Object-Oriented Programming (ECOOP) [https://netfiles.uiuc.edu/dig/RefactoringWorkshop/] at Berlin. Various papers like automated refactoring for improved cohesion, reuse based refactoring tools, Engineering reusability for software refactoring tools and others were presented and discussed. The proceedings of the first workshop can be found as a TU Berlin Technical Report, ISSN 1436-9915.

The second workshop on refactoring tools was conducted on October 19th 2008 in conjunction with Object-Oriented Programming Systems, Languages and Applications (OOPSLA) [https://netfiles.uiuc.edu/dig/RefactoringInfo/WRT08/] at Nashville, Tennessee. Various papers that were accepted and discussed were Cross Language Refactoring for Eclipse plug-ins, Tool support for refactoring functional programs, Towards a Refactoring guideline using code clone classification and others. More accepted papers at the second workshop can be found at [https://agora.cs.illinois.edu/display/wrt08/Accepted+Papers]. The interest in research in refactoring tools has increased to a greater extent that more papers were submitted and more researchers and tool vendors like JetBrains, Microsoft participated at the workshop.

The third workshop on refactoring tools is going to be held on October 25-29, 2009 in conjunction with Object-Oriented Programming Systems, Languages and Applications (OOPSLA) [https://netfiles.uiuc.edu/dig/RefactoringInfo/WRT09/] at Orlando, Florida. The papers have been invited for the topics which include language-independent transformation frameworks, language-independent analysis frameworks and analytical representations.

=== '''Ongoing Research''' ===

Refactoring in general preserves the behavior of the program during restructuring. But with the metaphor of extended language, the refactoring can be done in an efficient manner. The extended language implementation technique is all about embedding the source code into the extended language where the refactoring is easier to perform and then translating the refactored code into original language. This has been implemented on the well-known refactoring ‘Extract Method’ which showed the results that overall refactoring can be decomposed into micro-refactorings which are easy to implement and test.

Another improvement in which a tool can provide is the refactoring based on invariant preservation rather on the regular pre-condition based. The program invariants are nothing but the predicates about the objects state and their relationships which remain valid for every execution of program. There are quite a few initiatives that can be taken as part of the future research, which include the structural refactorings ‘Encapsulate Field’[http://sourcemaking.com/refactoring/encapsulate-field] or ‘Move Method’[http://www.refactoring.com/catalog/moveMethod.html] implementation using the micro-refactoring (refactorings which are used to perform small restructuring at once) decomposition approach. The above research is being conducted by the Programming Tools Group at University of Oxford.More information on this research can be found at [http://progtools.comlab.ox.ac.uk/projects/refactoring/ecoop09.pdf]

Lots of initiatives are being taken by tool vendors to improve refactoring tools. One such case is Net Beans where research is being carried on in this arena. The “replace method code duplicate” feature is being designed to locate selected method code repetitions and turn them in to a method call. The “generify” feature is currently developed for the transformation of non – generic code in to generic aware code. The “copy class” feature is currently in experimental stage to tap the feature of refactoring that allows to copy an existing class or interface. Likewise other features like “Inline method” which is used to inline a method, “Introduce variable” and “Clean up” are currently developed in their labs.

=== '''Other Initiatives''' ===

Apart from workshops held specifically for refactoring tools, other conferences have been organized by Automated Software Engineering (ASE), International Conference on Software Engineering (ICSE), Foundations of Software Engineering (FSE) wherein papers on refactoring have been presented and awarded the best paper award.

In addition to the workshops and conferences, the weekly contest on refactoring “Refactor It! The Weekly Book Giveaway” has been started by Billy McCafferty to increase the awareness and interest among the software developers, students and other programming communities. Various groups like Software Architecture Group (SAG) at University of Illinois at Urbana-Champaign, Program Analysis and Transformation (PAT) group at IBM TJ Watson Research Center have been organized at Universities and Organizations to conduct research in refactoring tools and to improve the current generation of refactoring tools. More details about various groups and people can be found at [https://netfiles.uiuc.edu/dig/RefactoringInfo/people.html]

== External Links ==

Refactor It contest [http://devlicio.us/blogs/billy_mccafferty/archive/2006/11/13/refactor-it-the-weekly-book-giveaway.aspx]

Refactoring tool for .NET [http://submain.com/products/codeit.once.aspx]

=== '''Books''' ===

Refactoring Workbook - William.C.Wake [http://www.amazon.com/exec/obidos/tg/detail/-/0321109295]

Refactoring to Patterns - [http://industriallogic.com/xp/refactoring/]

Refactoring Databases : Evolutionary Database Design - [http://www.amazon.com/exec/obidos/ASIN/0321293533]

Professional Refactoring in Visual Basic - [http://www.amazon.com/gp/product/0470179791]

CoreJ2EE Patterns - [http://www.amazon.com/Core-J2EE-Patterns-Practices-Strategies/dp/0131422464]

== References ==

=== '''Thesis Works''' ===

William F. Opdyke, Refactoring object-oriented frameworks, University of Illinois at Urbana-Champaign, Champaign, IL, 1992 [http://portal.acm.org/citation.cfm?id=169783&dl=GUIDE&coll=GUIDE&CFID=50708246&CFTOKEN=47231553]

Refactoring as Formal Refinements- Marico Lopes Cornelio [http://dsc.upe.br/~mlc/PhDThesis/RefactoringsAsFormalRefinements.pdf]

Practical Analysis for Refactoring – Donald B Roberts, University of Illinois at Urbana-Champaign Champaign, IL, USA[http://portal.acm.org/citation.cfm?id=871251]

Refactoring Tools and Complementary Techniques - Martin Drozdz, Derrick G Kourie, Bruce W Watson, Andrew Boake Espresso Research Group, Department of Computer Science, University of Pretoria, Pretoria, South Africa 0001 [http://www2.computer.org/portal/web/csdl/doi/10.1109/AICCSA.2006.205164]

=== '''Other Papers/Conferences''' ===

William F. Opdyke and Ralph E. Johnson. Refactoring: An aid in designing application frameworks and evolving object-oriented systems. In Proceedings of Symposium on Object- Oriented Programming Emphasizing Practical Applications (SOOPPA), September 1990.

Refactoring, Reuse & Reality, Bill Opdyke, Lucent Technologies/ Bell Labs, Copyright 1999, Lucent Technologies[http://chip.cs.uiuc.edu/users/opdyke/wfo.990201.refac.html]

Why Don’t People Use Refactoring Tools? Emerson Murphy-Hill and Andrew P. Black, Portland State University [http://web.cecs.pdx.edu/~black/publications/WRT07.pdf?id=1176678&type=pdf&coll=&dl=acm&CFID=15151515&CFTOKEN=6184618]

First workshop on refactoring in conjunction with ecoop Berlin 07 [https://netfiles.uiuc.edu/dig/RefactoringWorkshop/]

Second ACM Workshop on Refactoring Tools (WRT'08)[https://netfiles.uiuc.edu/dig/RefactoringInfo/WRT08/]

Accepted papers for WRT’08 [https://agora.cs.illinois.edu/display/wrt08/Accepted+Papers]

Third ACM Workshop on Refactoring Tools (WRT'09)[https://netfiles.uiuc.edu/dig/RefactoringInfo/WRT09/]

ACM SIGSOFT 2006 / FSE 14[http://www.cs.uoregon.edu/fse-14/]

29th Int. Conference on Software Engineering® 20 - 26 May 2007[http://web4.cs.ucl.ac.uk/icse07/]

21st IEEE/ACM International Conference on Automated Software Engineering[http://ase.cs.uni-essen.de/ase/past/ase2006/]

=== '''Web''' ===

Refactoring Info[https://netfiles.uiuc.edu/dig/RefactoringInfo/index.html]

www.refactoring.com [http://www.refactoring.com/]

Refactoring at AllExperts [http://en.allexperts.com/e/r/re/refactoring.html]

Refactoring Tool - NetBeans [http://refactoring.netbeans.org/]

CSC/ECE 517 Fall 2009/wiki1a 9 DS

2009-09-16T02:16:57Z

Screenit: /* '''Ongoing Research''' */

'''Refactoring Tools - Academic Underpinnings and Improvement Initiatives'''

----

== Definition ==

Refactoring[http://en.wikipedia.org/wiki/Code_refactoring] is defined as the technique by which the existing body of the code is restructured by changing the inner structure and preserving its external behavior. More common refactorings that are available can be found here [http://www.refactoring.com/catalog/index.html]. The tools which are used to achieve this purpose are commonly known as refactoring tools.

Refactoring tools are provided as Integrated Development Environment (IDE) features currently and are available for all popular programming languages. For instance, the common IDEs that provide the refactoring tools are IBM’s Eclipse, Sun’s Netbeans and IntelliJ’s IDEA. For further information, an academic thesis “Refactoring Tools and Complementary Techniques” focuses on the survey made on the comparison of refactoring tools usage in IDEs.

Below is an example of refactoring "extract method"

Code Before refactoring

public class Refactoringjava {
public static void main(String args[]){
int a = 0,b =2,result;
result = a+b;
System.out.println("Sum =" + result);
}

Code after Refactoring

public class Refactoringjava {
public static void main(String args[]){
int a = 0,b =2,result;
result = sum(a,b);
System.out.println("Sum =" + result);
}
static int sum(int x,int y)
{
int sum = x+y;
return(sum);
}

== Overview ==
This deals with the academic underpinnings of refactoring starting from its evolution and the initiatives taken to improve the current generation of refactoring tools.In addition, this discusses the on going research initiatives to enhance the features in refactoring tools. It also throws lights up on various books, academic thesis, conferences and workshops on the topic of refactoring.

== Academic Underpinnings ==

=== '''Motivation''' ===

The first official thesis on the area of refactoring leads back to 1992 when Bill Opdyke finished his thesis on the topic "Refactoring Object-Oriented Frameworks"[http://portal.acm.org/citation.cfm?id=169783&dl=GUIDE&coll=GUIDE&CFID=50708246&CFTOKEN=47231553]. Bill Opdyke was working in Bell Laboratories developing electronic switching systems.
When he started to pursue his doctoral studies he wanted it to be related to practical business applications. That is when he narrowed down on this topic which led to the official shaping of the cloud refactoring.

The Basic motivation behind the emergence of refactoring was the software re-usability and cutting down cost involved in restructuring software for various purposes. Thus refactoring leads to software reuse in future.

Though it might appear that refactoring began in research labs it actually emerged on an ad-hoc basis when object-oriented programmers came across situations where they felt the need for change in object oriented software. Refactoring actually has its roots way back. Factoring was a key technique in Forth Language from its birth in 70’s. Absence of appropriate syntax made it not possible to extract the best use out of it. Ralph Johnson was the first person to use the name refactoring in print. Along with Bill Opdyke he published a paper on refactoring in 1990.

=== '''Etymology''' ===

The first known use of the term “refactoring” appeared in “Refactoring: An Aid in Designing Application Frameworks and Evolving Object-Oriented Systems” by Ralph Johnson and Bill Opdyke in 1990. But Refactoring as a function and as a technique, was almost certainly used before then.

=== '''More Works''' ===

Lot of work has been done on this area which includes the thesis work “Practical Analysis for refactoring” [http://portal.acm.org/citation.cfm?id=871251] by Donald Bradley Roberts. It focuses on several ways to make a refactoring tool that is both fast and reliable enough to be useful. In another thesis work “Refactoring as Formal Refinements” [http://dsc.upe.br/~mlc/PhDThesis/RefactoringsAsFormalRefinements.pdf] by Márcio Cornélio throws light on algebraic technique that presents refactoring as behavior preserving transformation. For list of other thesis works and papers refer to the References section.

=== '''Books on Refactoring''' ===

Various books are available on the topic of refactoring these days. The initial list of books includes “Refactoring: Improving the Design of Existing Code“ [http://www.amazon.com/exec/obidos/ASIN/0201485672] by Martin Flower and Refactoring to Patterns [http://www.industriallogic.com/xp/refactoring/] by Joshua Kerievsky and many more books on this topic. For listing of books on refactoring refer to the external links.

== Initiatives taken to improve current generation of refactoring tools ==

Various initiatives like conferences, workshops are conducted by Organizations like Institute of Electrical and Electronics Engineers (IEEE), Associate for Computing Machinery (ACM) to improve the current generation of refactoring tools. The first initiative taken to improve the current generation of refactoring tools was the creation of the refactoring research web portal ([http://refactoring.info]).
This research web portal includes a collection of links and articles that provide the researchers and industrial engineers an up-to-date knowledge on refactoring.

=== '''Workshops and Conferences''' ===

The second initiative taken was, organization of workshops which serve as a forum to bring researchers and tool vendors together for collaborative efforts in developing the refactoring tools. This initiative has been taken with the motive to develop the tool support for refactoring efficiently by combining the state-of-the-art research with the challenges from real-time applications. The benefits of such workshops by collaborating the researchers and tool vendors are, to develop the tools in a short period of time and to eliminate the redundant works by other researchers and tool vendors. The workshops on refactoring tools are being conducted annually at various places

The first workshop on refactoring tools was conducted on July 31st 2007 in conjunction with European Conference on Object-Oriented Programming (ECOOP) [https://netfiles.uiuc.edu/dig/RefactoringWorkshop/] at Berlin. Various papers like automated refactoring for improved cohesion, reuse based refactoring tools, Engineering reusability for software refactoring tools and others were presented and discussed. The proceedings of the first workshop can be found as a TU Berlin Technical Report, ISSN 1436-9915.

The second workshop on refactoring tools was conducted on October 19th 2008 in conjunction with Object-Oriented Programming Systems, Languages and Applications (OOPSLA) [https://netfiles.uiuc.edu/dig/RefactoringInfo/WRT08/] at Nashville, Tennessee. Various papers that were accepted and discussed were Cross Language Refactoring for Eclipse plug-ins, Tool support for refactoring functional programs, Towards a Refactoring guideline using code clone classification and others. More accepted papers at the second workshop can be found at [https://agora.cs.illinois.edu/display/wrt08/Accepted+Papers]. The interest in research in refactoring tools has increased to a greater extent that more papers were submitted and more researchers and tool vendors like JetBrains, Microsoft participated at the workshop.

The third workshop on refactoring tools is going to be held on October 25-29, 2009 in conjunction with Object-Oriented Programming Systems, Languages and Applications (OOPSLA) [https://netfiles.uiuc.edu/dig/RefactoringInfo/WRT09/] at Orlando, Florida. The papers have been invited for the topics which include language-independent transformation frameworks, language-independent analysis frameworks and analytical representations.

=== '''Ongoing Research''' ===

Refactoring in general preserves the behavior of the program during restructuring. But with the metaphor of extended language, the refactoring can be done in an efficient manner. The extended language implementation technique is all about embedding the source code into the extended language where the refactoring is easier to perform and then translating the refactored code into original language. This has been implemented on the well-known refactoring ‘Extract Method’ which showed the results that overall refactoring can be decomposed into micro-refactorings which are easy to implement and test.

Another improvement in which a tool can provide is the refactoring based on invariant preservation rather on the regular pre-condition based. The program invariants are nothing but the predicates about the objects state and their relationships which remain valid for every execution of program. There are quite a few initiatives that can be taken as part of the future research, which include the structural refactorings ‘Encapsulate Field’[http://sourcemaking.com/refactoring/encapsulate-field] or ‘Move Method’[http://www.refactoring.com/catalog/moveMethod.html] implementation using the micro-refactoring (refactorings which are used to perform small restructuring at once) decomposition approach. The above research is being conducted by the Programming Tools Group at University of Oxford.More information on this research can be found at [http://progtools.comlab.ox.ac.uk/projects/refactoring/ecoop09.pdf]

Lots of initiatives are being taken by tool vendors to improve refactoring tools. One such case is Net Beans where research is being carried on in this arena. The “replace method code duplicate” feature is being designed to locate selected method code repetitions and turn them in to a method call. The “generify” feature is currently developed for the transformation of non – generic code in to generic aware code. The “copy class” feature is currently in experimental stage to tap the feature of refactoring that allows to copy an existing class or interface. Likewise other features like “Inline method” which is used to inline a method, “Introduce variable” and “Clean up” are currently developed in their labs.

=== '''Other Initiatives''' ===

Apart from workshops held specifically for refactoring tools, other conferences have been organized by Automated Software Engineering (ASE), International Conference on Software Engineering (ICSE), Foundations of Software Engineering (FSE) wherein papers on refactoring have been presented and awarded the best paper award.

In addition to the workshops and conferences, the weekly contest on refactoring “Refactor It! The Weekly Book Giveaway” has been started by Billy McCafferty to increase the awareness and interest among the software developers, students and other programming communities. Various groups like Software Architecture Group (SAG) at University of Illinois at Urbana-Champaign, Program Analysis and Transformation (PAT) group at IBM TJ Watson Research Center have been organized at Universities and Organizations to conduct research in refactoring tools and to improve the current generation of refactoring tools. More details about various groups and people can be found at [https://netfiles.uiuc.edu/dig/RefactoringInfo/people.html]

== External Links ==

Refactor It contest [http://devlicio.us/blogs/billy_mccafferty/archive/2006/11/13/refactor-it-the-weekly-book-giveaway.aspx]

Refactoring tool for .NET [http://submain.com/products/codeit.once.aspx]

=== '''Books''' ===

Refactoring Workbook - William.C.Wake [http://www.amazon.com/exec/obidos/tg/detail/-/0321109295]

Refactoring to Patterns - [http://industriallogic.com/xp/refactoring/]

Refactoring Databases : Evolutionary Database Design - [http://www.amazon.com/exec/obidos/ASIN/0321293533]

Professional Refactoring in Visual Basic - [http://www.amazon.com/gp/product/0470179791]

CoreJ2EE Patterns - [http://www.amazon.com/Core-J2EE-Patterns-Practices-Strategies/dp/0131422464]

== References ==

=== '''Thesis Works''' ===

William F. Opdyke, Refactoring object-oriented frameworks, University of Illinois at Urbana-Champaign, Champaign, IL, 1992 [http://portal.acm.org/citation.cfm?id=169783&dl=GUIDE&coll=GUIDE&CFID=50708246&CFTOKEN=47231553]

Refactoring as Formal Refinements- Marico Lopes Cornelio [http://dsc.upe.br/~mlc/PhDThesis/RefactoringsAsFormalRefinements.pdf]

Practical Analysis for Refactoring – Donald B Roberts, University of Illinois at Urbana-Champaign Champaign, IL, USA[http://portal.acm.org/citation.cfm?id=871251]

Refactoring Tools and Complementary Techniques - Martin Drozdz, Derrick G Kourie, Bruce W Watson, Andrew Boake Espresso Research Group, Department of Computer Science, University of Pretoria, Pretoria, South Africa 0001 [http://www2.computer.org/portal/web/csdl/doi/10.1109/AICCSA.2006.205164]

=== '''Other Papers/Conferences''' ===

William F. Opdyke and Ralph E. Johnson. Refactoring: An aid in designing application frameworks and evolving object-oriented systems. In Proceedings of Symposium on Object- Oriented Programming Emphasizing Practical Applications (SOOPPA), September 1990.

Refactoring, Reuse & Reality, Bill Opdyke, Lucent Technologies/ Bell Labs, Copyright 1999, Lucent Technologies[http://chip.cs.uiuc.edu/users/opdyke/wfo.990201.refac.html]

Why Don’t People Use Refactoring Tools? Emerson Murphy-Hill and Andrew P. Black, Portland State University [http://web.cecs.pdx.edu/~black/publications/WRT07.pdf?id=1176678&type=pdf&coll=&dl=acm&CFID=15151515&CFTOKEN=6184618]

First workshop on refactoring in conjunction with ecoop Berlin 07 [https://netfiles.uiuc.edu/dig/RefactoringWorkshop/]

Second ACM Workshop on Refactoring Tools (WRT'08)[https://netfiles.uiuc.edu/dig/RefactoringInfo/WRT08/]

Accepted papers for WRT’08 [https://agora.cs.illinois.edu/display/wrt08/Accepted+Papers]

Third ACM Workshop on Refactoring Tools (WRT'09)[https://netfiles.uiuc.edu/dig/RefactoringInfo/WRT09/]

ACM SIGSOFT 2006 / FSE 14[http://www.cs.uoregon.edu/fse-14/]

29th Int. Conference on Software Engineering® 20 - 26 May 2007[http://web4.cs.ucl.ac.uk/icse07/]

21st IEEE/ACM International Conference on Automated Software Engineering[http://ase.cs.uni-essen.de/ase/past/ase2006/]

=== '''Web''' ===

Refactoring Info[https://netfiles.uiuc.edu/dig/RefactoringInfo/index.html]

www.refactoring.com [http://www.refactoring.com/]

Refactoring at AllExperts [http://en.allexperts.com/e/r/re/refactoring.html]

Refactoring Tool - NetBeans [http://refactoring.netbeans.org/]

CSC/ECE 517 Fall 2009/wiki1a 9 DS

2009-09-16T02:02:31Z

Screenit: /* '''Ongoing Research''' */

'''Refactoring Tools - Academic Underpinnings and Improvement Initiatives'''

----

== Definition ==

Refactoring[http://en.wikipedia.org/wiki/Code_refactoring] is defined as the technique by which the existing body of the code is restructured by changing the inner structure and preserving its external behavior. More common refactorings that are available can be found here [http://www.refactoring.com/catalog/index.html]. The tools which are used to achieve this purpose are commonly known as refactoring tools.

Refactoring tools are provided as Integrated Development Environment (IDE) features currently and are available for all popular programming languages. For instance, the common IDEs that provide the refactoring tools are IBM’s Eclipse, Sun’s Netbeans and IntelliJ’s IDEA. For further information, an academic thesis “Refactoring Tools and Complementary Techniques” focuses on the survey made on the comparison of refactoring tools usage in IDEs.

Below is an example of refactoring "extract method"

Code Before refactoring

public class Refactoringjava {
public static void main(String args[]){
int a = 0,b =2,result;
result = a+b;
System.out.println("Sum =" + result);
}

Code after Refactoring

public class Refactoringjava {
public static void main(String args[]){
int a = 0,b =2,result;
result = sum(a,b);
System.out.println("Sum =" + result);
}
static int sum(int x,int y)
{
int sum = x+y;
return(sum);
}

== Overview ==
This deals with the academic underpinnings of refactoring starting from its evolution and the initiatives taken to improve the current generation of refactoring tools.In addition, this discusses the on going research initiatives to enhance the features in refactoring tools. It also throws lights up on various books, academic thesis, conferences and workshops on the topic of refactoring.

== Academic Underpinnings ==

=== '''Motivation''' ===

The first official thesis on the area of refactoring leads back to 1992 when Bill Opdyke finished his thesis on the topic "Refactoring Object-Oriented Frameworks"[http://portal.acm.org/citation.cfm?id=169783&dl=GUIDE&coll=GUIDE&CFID=50708246&CFTOKEN=47231553]. Bill Opdyke was working in Bell Laboratories developing electronic switching systems.
When he started to pursue his doctoral studies he wanted it to be related to practical business applications. That is when he narrowed down on this topic which led to the official shaping of the cloud refactoring.

The Basic motivation behind the emergence of refactoring was the software re-usability and cutting down cost involved in restructuring software for various purposes. Thus refactoring leads to software reuse in future.

Though it might appear that refactoring began in research labs it actually emerged on an ad-hoc basis when object-oriented programmers came across situations where they felt the need for change in object oriented software. Refactoring actually has its roots way back. Factoring was a key technique in Forth Language from its birth in 70’s. Absence of appropriate syntax made it not possible to extract the best use out of it. Ralph Johnson was the first person to use the name refactoring in print. Along with Bill Opdyke he published a paper on refactoring in 1990.

=== '''Etymology''' ===

The first known use of the term “refactoring” appeared in “Refactoring: An Aid in Designing Application Frameworks and Evolving Object-Oriented Systems” by Ralph Johnson and Bill Opdyke in 1990. But Refactoring as a function and as a technique, was almost certainly used before then.

=== '''More Works''' ===

Lot of work has been done on this area which includes the thesis work “Practical Analysis for refactoring” [http://portal.acm.org/citation.cfm?id=871251] by Donald Bradley Roberts. It focuses on several ways to make a refactoring tool that is both fast and reliable enough to be useful. In another thesis work “Refactoring as Formal Refinements” [http://dsc.upe.br/~mlc/PhDThesis/RefactoringsAsFormalRefinements.pdf] by Márcio Cornélio throws light on algebraic technique that presents refactoring as behavior preserving transformation. For list of other thesis works and papers refer to the References section.

=== '''Books on Refactoring''' ===

Various books are available on the topic of refactoring these days. The initial list of books includes “Refactoring: Improving the Design of Existing Code“ [http://www.amazon.com/exec/obidos/ASIN/0201485672] by Martin Flower and Refactoring to Patterns [http://www.industriallogic.com/xp/refactoring/] by Joshua Kerievsky and many more books on this topic. For listing of books on refactoring refer to the external links.

== Initiatives taken to improve current generation of refactoring tools ==

Various initiatives like conferences, workshops are conducted by Organizations like Institute of Electrical and Electronics Engineers (IEEE), Associate for Computing Machinery (ACM) to improve the current generation of refactoring tools. The first initiative taken to improve the current generation of refactoring tools was the creation of the refactoring research web portal ([http://refactoring.info]).
This research web portal includes a collection of links and articles that provide the researchers and industrial engineers an up-to-date knowledge on refactoring.

=== '''Workshops and Conferences''' ===

The second initiative taken was, organization of workshops which serve as a forum to bring researchers and tool vendors together for collaborative efforts in developing the refactoring tools. This initiative has been taken with the motive to develop the tool support for refactoring efficiently by combining the state-of-the-art research with the challenges from real-time applications. The benefits of such workshops by collaborating the researchers and tool vendors are, to develop the tools in a short period of time and to eliminate the redundant works by other researchers and tool vendors. The workshops on refactoring tools are being conducted annually at various places

The first workshop on refactoring tools was conducted on July 31st 2007 in conjunction with European Conference on Object-Oriented Programming (ECOOP) [https://netfiles.uiuc.edu/dig/RefactoringWorkshop/] at Berlin. Various papers like automated refactoring for improved cohesion, reuse based refactoring tools, Engineering reusability for software refactoring tools and others were presented and discussed. The proceedings of the first workshop can be found as a TU Berlin Technical Report, ISSN 1436-9915.

The second workshop on refactoring tools was conducted on October 19th 2008 in conjunction with Object-Oriented Programming Systems, Languages and Applications (OOPSLA) [https://netfiles.uiuc.edu/dig/RefactoringInfo/WRT08/] at Nashville, Tennessee. Various papers that were accepted and discussed were Cross Language Refactoring for Eclipse plug-ins, Tool support for refactoring functional programs, Towards a Refactoring guideline using code clone classification and others. More accepted papers at the second workshop can be found at [https://agora.cs.illinois.edu/display/wrt08/Accepted+Papers]. The interest in research in refactoring tools has increased to a greater extent that more papers were submitted and more researchers and tool vendors like JetBrains, Microsoft participated at the workshop.

The third workshop on refactoring tools is going to be held on October 25-29, 2009 in conjunction with Object-Oriented Programming Systems, Languages and Applications (OOPSLA) [https://netfiles.uiuc.edu/dig/RefactoringInfo/WRT09/] at Orlando, Florida. The papers have been invited for the topics which include language-independent transformation frameworks, language-independent analysis frameworks and analytical representations.

=== '''Ongoing Research''' ===

Refactoring in general preserves the behavior of the program during restructuring. But with the metaphor of extended language, the refactoring can be done in an efficient manner. The extended language implementation technique is all about embedding the source code into the extended language where the refactoring is easier to perform and then translating the refactored code into original language. This has been implemented on the well-known refactoring ‘Extract Method’ which showed the results that overall refactoring can be decomposed into micro-refactorings which are easy to implement and test.

Another improvement in which a tool can provide is the refactoring based on invariant preservation rather on the regular pre-condition based. The program invariants are nothing but the predicates about the objects state and their relationships which remain valid for every execution of program. There are quite a few initiatives that can be taken as part of the future research, which include the structural refactorings ‘Encapsulate Field’[http://sourcemaking.com/refactoring/encapsulate-field] or ‘Move Method’[http://www.refactoring.com/catalog/moveMethod.html] implementation using the micro-refactoring decomposition approach. The above research is being conducted by the Programming Tools Group at University of Oxford.More information on this research can be found at [http://progtools.comlab.ox.ac.uk/projects/refactoring/ecoop09.pdf]

Lots of initiatives are being taken by tool vendors to improve refactoring tools. One such case is Net Beans where research is being carried on in this arena. The “replace method code duplicate” feature is being designed to locate selected method code repetitions and turn them in to a method call. The “generify” feature is currently developed for the transformation of non – generic code in to generic aware code. The “copy class” feature is currently in experimental stage to tap the feature of refactoring that allows to copy an existing class or interface. Likewise other features like “Inline method” which is used to inline a method, “Introduce variable” and “Clean up” are currently developed in their labs.

=== '''Other Initiatives''' ===

Apart from workshops held specifically for refactoring tools, other conferences have been organized by Automated Software Engineering (ASE), International Conference on Software Engineering (ICSE), Foundations of Software Engineering (FSE) wherein papers on refactoring have been presented and awarded the best paper award.

In addition to the workshops and conferences, the weekly contest on refactoring “Refactor It! The Weekly Book Giveaway” has been started by Billy McCafferty to increase the awareness and interest among the software developers, students and other programming communities. Various groups like Software Architecture Group (SAG) at University of Illinois at Urbana-Champaign, Program Analysis and Transformation (PAT) group at IBM TJ Watson Research Center have been organized at Universities and Organizations to conduct research in refactoring tools and to improve the current generation of refactoring tools. More details about various groups and people can be found at [https://netfiles.uiuc.edu/dig/RefactoringInfo/people.html]

== External Links ==

Refactor It contest [http://devlicio.us/blogs/billy_mccafferty/archive/2006/11/13/refactor-it-the-weekly-book-giveaway.aspx]

Refactoring tool for .NET [http://submain.com/products/codeit.once.aspx]

=== '''Books''' ===

Refactoring Workbook - William.C.Wake [http://www.amazon.com/exec/obidos/tg/detail/-/0321109295]

Refactoring to Patterns - [http://industriallogic.com/xp/refactoring/]

Refactoring Databases : Evolutionary Database Design - [http://www.amazon.com/exec/obidos/ASIN/0321293533]

Professional Refactoring in Visual Basic - [http://www.amazon.com/gp/product/0470179791]

CoreJ2EE Patterns - [http://www.amazon.com/Core-J2EE-Patterns-Practices-Strategies/dp/0131422464]

== References ==

=== '''Thesis Works''' ===

William F. Opdyke, Refactoring object-oriented frameworks, University of Illinois at Urbana-Champaign, Champaign, IL, 1992 [http://portal.acm.org/citation.cfm?id=169783&dl=GUIDE&coll=GUIDE&CFID=50708246&CFTOKEN=47231553]

Refactoring as Formal Refinements- Marico Lopes Cornelio [http://dsc.upe.br/~mlc/PhDThesis/RefactoringsAsFormalRefinements.pdf]

Practical Analysis for Refactoring – Donald B Roberts, University of Illinois at Urbana-Champaign Champaign, IL, USA[http://portal.acm.org/citation.cfm?id=871251]

Refactoring Tools and Complementary Techniques - Martin Drozdz, Derrick G Kourie, Bruce W Watson, Andrew Boake Espresso Research Group, Department of Computer Science, University of Pretoria, Pretoria, South Africa 0001 [http://www2.computer.org/portal/web/csdl/doi/10.1109/AICCSA.2006.205164]

=== '''Other Papers/Conferences''' ===

William F. Opdyke and Ralph E. Johnson. Refactoring: An aid in designing application frameworks and evolving object-oriented systems. In Proceedings of Symposium on Object- Oriented Programming Emphasizing Practical Applications (SOOPPA), September 1990.

Refactoring, Reuse & Reality, Bill Opdyke, Lucent Technologies/ Bell Labs, Copyright 1999, Lucent Technologies[http://chip.cs.uiuc.edu/users/opdyke/wfo.990201.refac.html]

Why Don’t People Use Refactoring Tools? Emerson Murphy-Hill and Andrew P. Black, Portland State University [http://web.cecs.pdx.edu/~black/publications/WRT07.pdf?id=1176678&type=pdf&coll=&dl=acm&CFID=15151515&CFTOKEN=6184618]

First workshop on refactoring in conjunction with ecoop Berlin 07 [https://netfiles.uiuc.edu/dig/RefactoringWorkshop/]

Second ACM Workshop on Refactoring Tools (WRT'08)[https://netfiles.uiuc.edu/dig/RefactoringInfo/WRT08/]

Accepted papers for WRT’08 [https://agora.cs.illinois.edu/display/wrt08/Accepted+Papers]

Third ACM Workshop on Refactoring Tools (WRT'09)[https://netfiles.uiuc.edu/dig/RefactoringInfo/WRT09/]

ACM SIGSOFT 2006 / FSE 14[http://www.cs.uoregon.edu/fse-14/]

29th Int. Conference on Software Engineering® 20 - 26 May 2007[http://web4.cs.ucl.ac.uk/icse07/]

21st IEEE/ACM International Conference on Automated Software Engineering[http://ase.cs.uni-essen.de/ase/past/ase2006/]

=== '''Web''' ===

Refactoring Info[https://netfiles.uiuc.edu/dig/RefactoringInfo/index.html]

www.refactoring.com [http://www.refactoring.com/]

Refactoring at AllExperts [http://en.allexperts.com/e/r/re/refactoring.html]

Refactoring Tool - NetBeans [http://refactoring.netbeans.org/]

CSC/ECE 517 Fall 2009/wiki1a 9 DS

2009-09-16T01:26:38Z

Screenit:

'''Refactoring Tools - Academic Underpinnings and Improvement Initiatives'''

----

== Definition ==

Refactoring[http://en.wikipedia.org/wiki/Code_refactoring] is defined as the technique by which the existing body of the code is restructured by changing the inner structure and preserving its external behavior. More common refactorings that are available can be found here [http://www.refactoring.com/catalog/index.html]. The tools which are used to achieve this purpose are commonly known as refactoring tools.

Refactoring tools are provided as Integrated Development Environment (IDE) features currently and are available for all popular programming languages. For instance, the common IDEs that provide the refactoring tools are IBM’s Eclipse, Sun’s Netbeans and IntelliJ’s IDEA. For further information, an academic thesis “Refactoring Tools and Complementary Techniques” focuses on the survey made on the comparison of refactoring tools usage in IDEs.

Below is an example of refactoring "extract method"

Code Before refactoring

public class Refactoringjava {
public static void main(String args[]){
int a = 0,b =2,result;
result = a+b;
System.out.println("Sum =" + result);
}

Code after Refactoring

public class Refactoringjava {
public static void main(String args[]){
int a = 0,b =2,result;
result = sum(a,b);
System.out.println("Sum =" + result);
}
static int sum(int x,int y)
{
int sum = x+y;
return(sum);
}

== Overview ==
This deals with the academic underpinnings of refactoring starting from its evolution and the initiatives taken to improve the current generation of refactoring tools.In addition, this discusses the on going research initiatives to enhance the features in refactoring tools. It also throws lights up on various books, academic thesis, conferences and workshops on the topic of refactoring.

== Academic Underpinnings ==

=== '''Motivation''' ===

The first official thesis on the area of refactoring leads back to 1992 when Bill Opdyke finished his thesis on the topic "Refactoring Object-Oriented Frameworks"[http://portal.acm.org/citation.cfm?id=169783&dl=GUIDE&coll=GUIDE&CFID=50708246&CFTOKEN=47231553]. Bill Opdyke was working in Bell Laboratories developing electronic switching systems.
When he started to pursue his doctoral studies he wanted it to be related to practical business applications. That is when he narrowed down on this topic which led to the official shaping of the cloud refactoring.

The Basic motivation behind the emergence of refactoring was the software re-usability and cutting down cost involved in restructuring software for various purposes. Thus refactoring leads to software reuse in future.

Though it might appear that refactoring began in research labs it actually emerged on an ad-hoc basis when object-oriented programmers came across situations where they felt the need for change in object oriented software. Refactoring actually has its roots way back. Factoring was a key technique in Forth Language from its birth in 70’s. Absence of appropriate syntax made it not possible to extract the best use out of it. Ralph Johnson was the first person to use the name refactoring in print. Along with Bill Opdyke he published a paper on refactoring in 1990.

=== '''Etymology''' ===

The first known use of the term “refactoring” appeared in “Refactoring: An Aid in Designing Application Frameworks and Evolving Object-Oriented Systems” by Ralph Johnson and Bill Opdyke in 1990. But Refactoring as a function and as a technique, was almost certainly used before then.

=== '''More Works''' ===

Lot of work has been done on this area which includes the thesis work “Practical Analysis for refactoring” [http://portal.acm.org/citation.cfm?id=871251] by Donald Bradley Roberts. It focuses on several ways to make a refactoring tool that is both fast and reliable enough to be useful. In another thesis work “Refactoring as Formal Refinements” [http://dsc.upe.br/~mlc/PhDThesis/RefactoringsAsFormalRefinements.pdf] by Márcio Cornélio throws light on algebraic technique that presents refactoring as behavior preserving transformation. For list of other thesis works and papers refer to the References section.

=== '''Books on Refactoring''' ===

Various books are available on the topic of refactoring these days. The initial list of books includes “Refactoring: Improving the Design of Existing Code“ [http://www.amazon.com/exec/obidos/ASIN/0201485672] by Martin Flower and Refactoring to Patterns [http://www.industriallogic.com/xp/refactoring/] by Joshua Kerievsky and many more books on this topic. For listing of books on refactoring refer to the external links.

== Initiatives taken to improve current generation of refactoring tools ==

Various initiatives like conferences, workshops are conducted by Organizations like Institute of Electrical and Electronics Engineers (IEEE), Associate for Computing Machinery (ACM) to improve the current generation of refactoring tools. The first initiative taken to improve the current generation of refactoring tools was the creation of the refactoring research web portal ([http://refactoring.info]).
This research web portal includes a collection of links and articles that provide the researchers and industrial engineers an up-to-date knowledge on refactoring.

=== '''Workshops and Conferences''' ===

The second initiative taken was, organization of workshops which serve as a forum to bring researchers and tool vendors together for collaborative efforts in developing the refactoring tools. This initiative has been taken with the motive to develop the tool support for refactoring efficiently by combining the state-of-the-art research with the challenges from real-time applications. The benefits of such workshops by collaborating the researchers and tool vendors are, to develop the tools in a short period of time and to eliminate the redundant works by other researchers and tool vendors. The workshops on refactoring tools are being conducted annually at various places

The first workshop on refactoring tools was conducted on July 31st 2007 in conjunction with European Conference on Object-Oriented Programming (ECOOP) [https://netfiles.uiuc.edu/dig/RefactoringWorkshop/] at Berlin. Various papers like automated refactoring for improved cohesion, reuse based refactoring tools, Engineering reusability for software refactoring tools and others were presented and discussed. The proceedings of the first workshop can be found as a TU Berlin Technical Report, ISSN 1436-9915.

The second workshop on refactoring tools was conducted on October 19th 2008 in conjunction with Object-Oriented Programming Systems, Languages and Applications (OOPSLA) [https://netfiles.uiuc.edu/dig/RefactoringInfo/WRT08/] at Nashville, Tennessee. Various papers that were accepted and discussed were Cross Language Refactoring for Eclipse plug-ins, Tool support for refactoring functional programs, Towards a Refactoring guideline using code clone classification and others. More accepted papers at the second workshop can be found at [https://agora.cs.illinois.edu/display/wrt08/Accepted+Papers]. The interest in research in refactoring tools has increased to a greater extent that more papers were submitted and more researchers and tool vendors like JetBrains, Microsoft participated at the workshop.

The third workshop on refactoring tools is going to be held on October 25-29, 2009 in conjunction with Object-Oriented Programming Systems, Languages and Applications (OOPSLA) [https://netfiles.uiuc.edu/dig/RefactoringInfo/WRT09/] at Orlando, Florida. The papers have been invited for the topics which include language-independent transformation frameworks, language-independent analysis frameworks and analytical representations.

=== '''Ongoing Research''' ===

Refactoring in general preserves the behavior of the program during restructuring. But with the metaphor of extended language, the refactoring can be done in an efficient manner. The extended language implementation technique is all about embedding the source code into the extended language where the refactoring is easier to perform and then translating the refactored code into original language. This has been implemented on the well-known refactoring ‘Extract Method’ which showed the results that overall refactoring can be decomposed into micro-refactorings which are easy to implement and test.

Another improvement in which a tool can provide is the refactoring based on invariant preservation rather on the regular pre-condition based. The program invariants are nothing but the predicates about the objects state and their relationships which remain valid for every execution of program. There are quite a few initiatives that can be taken as part of the future research, which include the structural refactorings ‘Encapsulate Field’ or ‘Move Method’ implementation using the micro-refactoring decomposition approach. The above research is being conducted by the Programming Tools Group at University of Oxford.More information on this research can be found at [http://progtools.comlab.ox.ac.uk/projects/refactoring/ecoop09.pdf]

Lots of initiatives are being taken by tool vendors to improve refactoring tools. One such case is Net Beans where research is being carried on in this arena. The “replace method code duplicate” feature is being designed to locate selected method code repetitions and turn them in to a method call. The “generify” feature is currently developed for the transformation of non – generic code in to generic aware code. The “copy class” feature is currently in experimental stage to tap the feature of refactoring that allows to copy an existing class or interface. Likewise other features like “Inline method” which is used to inline a method, “Introduce variable” and “Clean up” are currently developed in their labs.

=== '''Other Initiatives''' ===

Apart from workshops held specifically for refactoring tools, other conferences have been organized by Automated Software Engineering (ASE), International Conference on Software Engineering (ICSE), Foundations of Software Engineering (FSE) wherein papers on refactoring have been presented and awarded the best paper award.

In addition to the workshops and conferences, the weekly contest on refactoring “Refactor It! The Weekly Book Giveaway” has been started by Billy McCafferty to increase the awareness and interest among the software developers, students and other programming communities. Various groups like Software Architecture Group (SAG) at University of Illinois at Urbana-Champaign, Program Analysis and Transformation (PAT) group at IBM TJ Watson Research Center have been organized at Universities and Organizations to conduct research in refactoring tools and to improve the current generation of refactoring tools. More details about various groups and people can be found at [https://netfiles.uiuc.edu/dig/RefactoringInfo/people.html]

== External Links ==

Refactor It contest [http://devlicio.us/blogs/billy_mccafferty/archive/2006/11/13/refactor-it-the-weekly-book-giveaway.aspx]

Refactoring tool for .NET [http://submain.com/products/codeit.once.aspx]

=== '''Books''' ===

Refactoring Workbook - William.C.Wake [http://www.amazon.com/exec/obidos/tg/detail/-/0321109295]

Refactoring to Patterns - [http://industriallogic.com/xp/refactoring/]

Refactoring Databases : Evolutionary Database Design - [http://www.amazon.com/exec/obidos/ASIN/0321293533]

Professional Refactoring in Visual Basic - [http://www.amazon.com/gp/product/0470179791]

CoreJ2EE Patterns - [http://www.amazon.com/Core-J2EE-Patterns-Practices-Strategies/dp/0131422464]

== References ==

=== '''Thesis Works''' ===

William F. Opdyke, Refactoring object-oriented frameworks, University of Illinois at Urbana-Champaign, Champaign, IL, 1992 [http://portal.acm.org/citation.cfm?id=169783&dl=GUIDE&coll=GUIDE&CFID=50708246&CFTOKEN=47231553]

Refactoring as Formal Refinements- Marico Lopes Cornelio [http://dsc.upe.br/~mlc/PhDThesis/RefactoringsAsFormalRefinements.pdf]

Practical Analysis for Refactoring – Donald B Roberts, University of Illinois at Urbana-Champaign Champaign, IL, USA[http://portal.acm.org/citation.cfm?id=871251]

Refactoring Tools and Complementary Techniques - Martin Drozdz, Derrick G Kourie, Bruce W Watson, Andrew Boake Espresso Research Group, Department of Computer Science, University of Pretoria, Pretoria, South Africa 0001 [http://www2.computer.org/portal/web/csdl/doi/10.1109/AICCSA.2006.205164]

=== '''Other Papers/Conferences''' ===

William F. Opdyke and Ralph E. Johnson. Refactoring: An aid in designing application frameworks and evolving object-oriented systems. In Proceedings of Symposium on Object- Oriented Programming Emphasizing Practical Applications (SOOPPA), September 1990.

Refactoring, Reuse & Reality, Bill Opdyke, Lucent Technologies/ Bell Labs, Copyright 1999, Lucent Technologies[http://chip.cs.uiuc.edu/users/opdyke/wfo.990201.refac.html]

Why Don’t People Use Refactoring Tools? Emerson Murphy-Hill and Andrew P. Black, Portland State University [http://web.cecs.pdx.edu/~black/publications/WRT07.pdf?id=1176678&type=pdf&coll=&dl=acm&CFID=15151515&CFTOKEN=6184618]

First workshop on refactoring in conjunction with ecoop Berlin 07 [https://netfiles.uiuc.edu/dig/RefactoringWorkshop/]

Second ACM Workshop on Refactoring Tools (WRT'08)[https://netfiles.uiuc.edu/dig/RefactoringInfo/WRT08/]

Accepted papers for WRT’08 [https://agora.cs.illinois.edu/display/wrt08/Accepted+Papers]

Third ACM Workshop on Refactoring Tools (WRT'09)[https://netfiles.uiuc.edu/dig/RefactoringInfo/WRT09/]

ACM SIGSOFT 2006 / FSE 14[http://www.cs.uoregon.edu/fse-14/]

29th Int. Conference on Software Engineering® 20 - 26 May 2007[http://web4.cs.ucl.ac.uk/icse07/]

21st IEEE/ACM International Conference on Automated Software Engineering[http://ase.cs.uni-essen.de/ase/past/ase2006/]

=== '''Web''' ===

Refactoring Info[https://netfiles.uiuc.edu/dig/RefactoringInfo/index.html]

www.refactoring.com [http://www.refactoring.com/]

Refactoring at AllExperts [http://en.allexperts.com/e/r/re/refactoring.html]

Refactoring Tool - NetBeans [http://refactoring.netbeans.org/]

CSC/ECE 517 Fall 2009/wiki1a 9 DS

2009-09-16T01:26:06Z

Screenit:

'''REFACTORING TOOLS - Academic Underpinnings and Improvement Initiatives'''

----

== Definition ==

Refactoring[http://en.wikipedia.org/wiki/Code_refactoring] is defined as the technique by which the existing body of the code is restructured by changing the inner structure and preserving its external behavior. More common refactorings that are available can be found here [http://www.refactoring.com/catalog/index.html]. The tools which are used to achieve this purpose are commonly known as refactoring tools.

Refactoring tools are provided as Integrated Development Environment (IDE) features currently and are available for all popular programming languages. For instance, the common IDEs that provide the refactoring tools are IBM’s Eclipse, Sun’s Netbeans and IntelliJ’s IDEA. For further information, an academic thesis “Refactoring Tools and Complementary Techniques” focuses on the survey made on the comparison of refactoring tools usage in IDEs.

Below is an example of refactoring "extract method"

Code Before refactoring

public class Refactoringjava {
public static void main(String args[]){
int a = 0,b =2,result;
result = a+b;
System.out.println("Sum =" + result);
}

Code after Refactoring

public class Refactoringjava {
public static void main(String args[]){
int a = 0,b =2,result;
result = sum(a,b);
System.out.println("Sum =" + result);
}
static int sum(int x,int y)
{
int sum = x+y;
return(sum);
}

== Overview ==
This deals with the academic underpinnings of refactoring starting from its evolution and the initiatives taken to improve the current generation of refactoring tools.In addition, this discusses the on going research initiatives to enhance the features in refactoring tools. It also throws lights up on various books, academic thesis, conferences and workshops on the topic of refactoring.

== Academic Underpinnings ==

=== '''Motivation''' ===

The first official thesis on the area of refactoring leads back to 1992 when Bill Opdyke finished his thesis on the topic "Refactoring Object-Oriented Frameworks"[http://portal.acm.org/citation.cfm?id=169783&dl=GUIDE&coll=GUIDE&CFID=50708246&CFTOKEN=47231553]. Bill Opdyke was working in Bell Laboratories developing electronic switching systems.
When he started to pursue his doctoral studies he wanted it to be related to practical business applications. That is when he narrowed down on this topic which led to the official shaping of the cloud refactoring.

The Basic motivation behind the emergence of refactoring was the software re-usability and cutting down cost involved in restructuring software for various purposes. Thus refactoring leads to software reuse in future.

Though it might appear that refactoring began in research labs it actually emerged on an ad-hoc basis when object-oriented programmers came across situations where they felt the need for change in object oriented software. Refactoring actually has its roots way back. Factoring was a key technique in Forth Language from its birth in 70’s. Absence of appropriate syntax made it not possible to extract the best use out of it. Ralph Johnson was the first person to use the name refactoring in print. Along with Bill Opdyke he published a paper on refactoring in 1990.

=== '''Etymology''' ===

The first known use of the term “refactoring” appeared in “Refactoring: An Aid in Designing Application Frameworks and Evolving Object-Oriented Systems” by Ralph Johnson and Bill Opdyke in 1990. But Refactoring as a function and as a technique, was almost certainly used before then.

=== '''More Works''' ===

Lot of work has been done on this area which includes the thesis work “Practical Analysis for refactoring” [http://portal.acm.org/citation.cfm?id=871251] by Donald Bradley Roberts. It focuses on several ways to make a refactoring tool that is both fast and reliable enough to be useful. In another thesis work “Refactoring as Formal Refinements” [http://dsc.upe.br/~mlc/PhDThesis/RefactoringsAsFormalRefinements.pdf] by Márcio Cornélio throws light on algebraic technique that presents refactoring as behavior preserving transformation. For list of other thesis works and papers refer to the References section.

=== '''Books on Refactoring''' ===

Various books are available on the topic of refactoring these days. The initial list of books includes “Refactoring: Improving the Design of Existing Code“ [http://www.amazon.com/exec/obidos/ASIN/0201485672] by Martin Flower and Refactoring to Patterns [http://www.industriallogic.com/xp/refactoring/] by Joshua Kerievsky and many more books on this topic. For listing of books on refactoring refer to the external links.

== Initiatives taken to improve current generation of refactoring tools ==

Various initiatives like conferences, workshops are conducted by Organizations like Institute of Electrical and Electronics Engineers (IEEE), Associate for Computing Machinery (ACM) to improve the current generation of refactoring tools. The first initiative taken to improve the current generation of refactoring tools was the creation of the refactoring research web portal ([http://refactoring.info]).
This research web portal includes a collection of links and articles that provide the researchers and industrial engineers an up-to-date knowledge on refactoring.

=== '''Workshops and Conferences''' ===

The second initiative taken was, organization of workshops which serve as a forum to bring researchers and tool vendors together for collaborative efforts in developing the refactoring tools. This initiative has been taken with the motive to develop the tool support for refactoring efficiently by combining the state-of-the-art research with the challenges from real-time applications. The benefits of such workshops by collaborating the researchers and tool vendors are, to develop the tools in a short period of time and to eliminate the redundant works by other researchers and tool vendors. The workshops on refactoring tools are being conducted annually at various places

The first workshop on refactoring tools was conducted on July 31st 2007 in conjunction with European Conference on Object-Oriented Programming (ECOOP) [https://netfiles.uiuc.edu/dig/RefactoringWorkshop/] at Berlin. Various papers like automated refactoring for improved cohesion, reuse based refactoring tools, Engineering reusability for software refactoring tools and others were presented and discussed. The proceedings of the first workshop can be found as a TU Berlin Technical Report, ISSN 1436-9915.

The second workshop on refactoring tools was conducted on October 19th 2008 in conjunction with Object-Oriented Programming Systems, Languages and Applications (OOPSLA) [https://netfiles.uiuc.edu/dig/RefactoringInfo/WRT08/] at Nashville, Tennessee. Various papers that were accepted and discussed were Cross Language Refactoring for Eclipse plug-ins, Tool support for refactoring functional programs, Towards a Refactoring guideline using code clone classification and others. More accepted papers at the second workshop can be found at [https://agora.cs.illinois.edu/display/wrt08/Accepted+Papers]. The interest in research in refactoring tools has increased to a greater extent that more papers were submitted and more researchers and tool vendors like JetBrains, Microsoft participated at the workshop.

The third workshop on refactoring tools is going to be held on October 25-29, 2009 in conjunction with Object-Oriented Programming Systems, Languages and Applications (OOPSLA) [https://netfiles.uiuc.edu/dig/RefactoringInfo/WRT09/] at Orlando, Florida. The papers have been invited for the topics which include language-independent transformation frameworks, language-independent analysis frameworks and analytical representations.

=== '''Ongoing Research''' ===

Refactoring in general preserves the behavior of the program during restructuring. But with the metaphor of extended language, the refactoring can be done in an efficient manner. The extended language implementation technique is all about embedding the source code into the extended language where the refactoring is easier to perform and then translating the refactored code into original language. This has been implemented on the well-known refactoring ‘Extract Method’ which showed the results that overall refactoring can be decomposed into micro-refactorings which are easy to implement and test.

Another improvement in which a tool can provide is the refactoring based on invariant preservation rather on the regular pre-condition based. The program invariants are nothing but the predicates about the objects state and their relationships which remain valid for every execution of program. There are quite a few initiatives that can be taken as part of the future research, which include the structural refactorings ‘Encapsulate Field’ or ‘Move Method’ implementation using the micro-refactoring decomposition approach. The above research is being conducted by the Programming Tools Group at University of Oxford.More information on this research can be found at [http://progtools.comlab.ox.ac.uk/projects/refactoring/ecoop09.pdf]

Lots of initiatives are being taken by tool vendors to improve refactoring tools. One such case is Net Beans where research is being carried on in this arena. The “replace method code duplicate” feature is being designed to locate selected method code repetitions and turn them in to a method call. The “generify” feature is currently developed for the transformation of non – generic code in to generic aware code. The “copy class” feature is currently in experimental stage to tap the feature of refactoring that allows to copy an existing class or interface. Likewise other features like “Inline method” which is used to inline a method, “Introduce variable” and “Clean up” are currently developed in their labs.

=== '''Other Initiatives''' ===

Apart from workshops held specifically for refactoring tools, other conferences have been organized by Automated Software Engineering (ASE), International Conference on Software Engineering (ICSE), Foundations of Software Engineering (FSE) wherein papers on refactoring have been presented and awarded the best paper award.

In addition to the workshops and conferences, the weekly contest on refactoring “Refactor It! The Weekly Book Giveaway” has been started by Billy McCafferty to increase the awareness and interest among the software developers, students and other programming communities. Various groups like Software Architecture Group (SAG) at University of Illinois at Urbana-Champaign, Program Analysis and Transformation (PAT) group at IBM TJ Watson Research Center have been organized at Universities and Organizations to conduct research in refactoring tools and to improve the current generation of refactoring tools. More details about various groups and people can be found at [https://netfiles.uiuc.edu/dig/RefactoringInfo/people.html]

== External Links ==

Refactor It contest [http://devlicio.us/blogs/billy_mccafferty/archive/2006/11/13/refactor-it-the-weekly-book-giveaway.aspx]

Refactoring tool for .NET [http://submain.com/products/codeit.once.aspx]

=== '''Books''' ===

Refactoring Workbook - William.C.Wake [http://www.amazon.com/exec/obidos/tg/detail/-/0321109295]

Refactoring to Patterns - [http://industriallogic.com/xp/refactoring/]

Refactoring Databases : Evolutionary Database Design - [http://www.amazon.com/exec/obidos/ASIN/0321293533]

Professional Refactoring in Visual Basic - [http://www.amazon.com/gp/product/0470179791]

CoreJ2EE Patterns - [http://www.amazon.com/Core-J2EE-Patterns-Practices-Strategies/dp/0131422464]

== References ==

=== '''Thesis Works''' ===

William F. Opdyke, Refactoring object-oriented frameworks, University of Illinois at Urbana-Champaign, Champaign, IL, 1992 [http://portal.acm.org/citation.cfm?id=169783&dl=GUIDE&coll=GUIDE&CFID=50708246&CFTOKEN=47231553]

Refactoring as Formal Refinements- Marico Lopes Cornelio [http://dsc.upe.br/~mlc/PhDThesis/RefactoringsAsFormalRefinements.pdf]

Practical Analysis for Refactoring – Donald B Roberts, University of Illinois at Urbana-Champaign Champaign, IL, USA[http://portal.acm.org/citation.cfm?id=871251]

Refactoring Tools and Complementary Techniques - Martin Drozdz, Derrick G Kourie, Bruce W Watson, Andrew Boake Espresso Research Group, Department of Computer Science, University of Pretoria, Pretoria, South Africa 0001 [http://www2.computer.org/portal/web/csdl/doi/10.1109/AICCSA.2006.205164]

=== '''Other Papers/Conferences''' ===

William F. Opdyke and Ralph E. Johnson. Refactoring: An aid in designing application frameworks and evolving object-oriented systems. In Proceedings of Symposium on Object- Oriented Programming Emphasizing Practical Applications (SOOPPA), September 1990.

Refactoring, Reuse & Reality, Bill Opdyke, Lucent Technologies/ Bell Labs, Copyright 1999, Lucent Technologies[http://chip.cs.uiuc.edu/users/opdyke/wfo.990201.refac.html]

Why Don’t People Use Refactoring Tools? Emerson Murphy-Hill and Andrew P. Black, Portland State University [http://web.cecs.pdx.edu/~black/publications/WRT07.pdf?id=1176678&type=pdf&coll=&dl=acm&CFID=15151515&CFTOKEN=6184618]

First workshop on refactoring in conjunction with ecoop Berlin 07 [https://netfiles.uiuc.edu/dig/RefactoringWorkshop/]

Second ACM Workshop on Refactoring Tools (WRT'08)[https://netfiles.uiuc.edu/dig/RefactoringInfo/WRT08/]

Accepted papers for WRT’08 [https://agora.cs.illinois.edu/display/wrt08/Accepted+Papers]

Third ACM Workshop on Refactoring Tools (WRT'09)[https://netfiles.uiuc.edu/dig/RefactoringInfo/WRT09/]

ACM SIGSOFT 2006 / FSE 14[http://www.cs.uoregon.edu/fse-14/]

29th Int. Conference on Software Engineering® 20 - 26 May 2007[http://web4.cs.ucl.ac.uk/icse07/]

21st IEEE/ACM International Conference on Automated Software Engineering[http://ase.cs.uni-essen.de/ase/past/ase2006/]

=== '''Web''' ===

Refactoring Info[https://netfiles.uiuc.edu/dig/RefactoringInfo/index.html]

www.refactoring.com [http://www.refactoring.com/]

Refactoring at AllExperts [http://en.allexperts.com/e/r/re/refactoring.html]

Refactoring Tool - NetBeans [http://refactoring.netbeans.org/]

CSC/ECE 517 Fall 2009/wiki1a 9 DS

2009-09-09T00:40:15Z

Screenit: /* References */

'''REFACTORING TOOLS'''

----

== Definition ==

Refactoring[http://en.wikipedia.org/wiki/Code_refactoring] is defined as the technique by which the existing body of the code is restructured by changing the inner structure and preserving its external behavior. More common refactorings that are available can be found here [http://www.refactoring.com/catalog/index.html]. The tools which are used to achieve this purpose are commonly known as Refactoring Tools.

Refactoring tools are provided as Integrated Development Environment (IDE) features currently and are available for all popular programming languages. For instance, the common IDEs that provide the refactoring tools are IBM’s Eclipse, Sun’s Netbeans and IntelliJ’s IDEA. For further information, an academic thesis “Refactoring Tools and Complementary Techniques” focuses on the survey made on the comparison of refactoring tools usage in IDEs.

Below is an example of refactoring "extract method"

Code Before refactoring

public class Refactoringjava {
public static void main(String args[]){
int a = 0,b =2,result;
result = a+b;
System.out.println("Sum =" + result);
}

Code after Refactoring

public class Refactoringjava {
public static void main(String args[]){
int a = 0,b =2,result;
result = sum(a,b);
System.out.println("Sum =" + result);
}
static int sum(int x,int y)
{
int sum = x+y;
return(sum);
}

== Overview ==
This deals with the academic underpinnings of refactoring starting from its evolution and the initiatives taken to improve the current generation of refactoring tools.In addition, this discusses the on going research initiatives to enhance the features in refactoring tools. It also throws lights up on various books, academic thesis, conferences and workshops on the topic of refactoring.

== Academic Underpinnings ==

=== '''Motivation''' ===

The first official thesis on the area of refactoring leads back to 1992 when Bill Opdyke finished his thesis on the topic "Refactoring Object-Oriented Frameworks"[http://portal.acm.org/citation.cfm?id=169783&dl=GUIDE&coll=GUIDE&CFID=50708246&CFTOKEN=47231553]. Bill Opdyke was working in Bell Laboratories developing electronic switching systems.
When he started to pursue his doctoral studies he wanted it to be related to practical business applications. That is when he narrowed down on this topic which led to the official shaping of the cloud refactoring.

The Basic motivation behind the emergence of refactoring was the software re-usability and cutting down cost involved in restructuring software for various purposes. Thus refactoring leads to software reuse in future.

Though it might appear that refactoring began in research labs it actually emerged on an ad-hoc basis when object-oriented programmers came across situations where they felt the need for change in object oriented software. Refactoring actually has its roots way back. Factoring was a key technique in Forth Language from its birth in 70’s. Absence of appropriate syntax made it not possible to extract the best use out of it. Ralph Johnson was the first person to use the name refactoring in print. Along with Bill Opdyke he published a paper on refactoring in 1990.

=== '''Etymology''' ===

The first known use of the term “refactoring” appeared in “Refactoring: An Aid in Designing Application Frameworks and Evolving Object-Oriented Systems” by Ralph Johnson and Bill Opdyke in 1990. But Refactoring as a function and as a technique, was almost certainly used before then.

=== '''More Works''' ===

Lot of work has been done on this area which includes the thesis work “Practical Analysis for refactoring” [http://portal.acm.org/citation.cfm?id=871251] by Donald Bradley Roberts. It focuses on several ways to make a refactoring tool that is both fast and reliable enough to be useful. In another thesis work “Refactoring as Formal Refinements” [http://dsc.upe.br/~mlc/PhDThesis/RefactoringsAsFormalRefinements.pdf] by Márcio Cornélio throws light on algebraic technique that presents refactoring as behavior preserving transformation. For list of other thesis works and papers refer to the References section.

=== '''Books on Refactoring''' ===

Various books are available on the topic of refactoring these days. The initial list of books includes “Refactoring: Improving the Design of Existing Code“ [http://www.amazon.com/exec/obidos/ASIN/0201485672] by Martin Flower and Refactoring to Patterns [http://www.industriallogic.com/xp/refactoring/] by Joshua Kerievsky and many more books on this topic. For listing of books on refactoring refer to the external links.

== Initiatives taken to improve current generation of refactoring tools ==

Various initiatives like conferences, workshops are conducted by Organizations like Institute of Electrical and Electronics Engineers (IEEE), Associate for Computing Machinery (ACM) to improve the current generation of refactoring tools. The first initiative taken to improve the current generation of refactoring tools was the creation of the refactoring research web portal ([http://refactoring.info]).
This research web portal includes a collection of links and articles that provide the researchers and industrial engineers an up-to-date knowledge on refactoring.

=== '''Workshops and Conferences''' ===

The second initiative taken was, organization of workshops which serve as a forum to bring researchers and tool vendors together for collaborative efforts in developing the refactoring tools. This initiative has been taken with the motive to develop the tool support for refactoring efficiently by combining the state-of-the-art research with the challenges from real-time applications. The benefits of such workshops by collaborating the researchers and tool vendors are, to develop the tools in a short period of time and to eliminate the redundant works by other researchers and tool vendors. The workshops on refactoring tools are being conducted annually at various places

The first workshop on refactoring tools was conducted on July 31st 2007 in conjunction with European Conference on Object-Oriented Programming (ECOOP) [https://netfiles.uiuc.edu/dig/RefactoringWorkshop/] at Berlin. Various papers like automated refactoring for improved cohesion, reuse based refactoring tools, Engineering reusability for software refactoring tools and others were presented and discussed. The proceedings of the first workshop can be found as a TU Berlin Technical Report, ISSN 1436-9915.

The second workshop on refactoring tools was conducted on October 19th 2008 in conjunction with Object-Oriented Programming Systems, Languages and Applications (OOPSLA) [https://netfiles.uiuc.edu/dig/RefactoringInfo/WRT08/] at Nashville, Tennessee. Various papers that were accepted and discussed were Cross Language Refactoring for Eclipse plug-ins, Tool support for refactoring functional programs, Towards a Refactoring guideline using code clone classification and others. More accepted papers at the second workshop can be found at [https://agora.cs.illinois.edu/display/wrt08/Accepted+Papers]. The interest in research in refactoring tools has increased to a greater extent that more papers were submitted and more researchers and tool vendors like JetBrains, Microsoft participated at the workshop.

The third workshop on refactoring tools is going to be held on October 25-29, 2009 in conjunction with Object-Oriented Programming Systems, Languages and Applications (OOPSLA) [https://netfiles.uiuc.edu/dig/RefactoringInfo/WRT09/] at Orlando, Florida. The papers have been invited for the topics which include language-independent transformation frameworks, language-independent analysis frameworks and analytical representations.

=== '''Ongoing Research''' ===

Refactoring in general preserves the behavior of the program during restructuring. But with the metaphor of extended language, the refactoring can be done in an efficient manner. The extended language implementation technique is all about embedding the source code into the extended language where the refactoring is easier to perform and then translating the refactored code into original language. This has been implemented on the well-known refactoring ‘Extract Method’ which showed the results that overall refactoring can be decomposed into micro-refactorings which are easy to implement and test.

Another improvement in which a tool can provide is the refactoring based on invariant preservation rather on the regular pre-condition based. The program invariants are nothing but the predicates about the objects state and their relationships which remain valid for every execution of program. There are quite a few initiatives that can be taken as part of the future research, which include the structural refactorings ‘Encapsulate Field’ or ‘Move Method’ implementation using the micro-refactoring decomposition approach. The above research is being conducted by the Programming Tools Group at University of Oxford.More information on this research can be found at [http://progtools.comlab.ox.ac.uk/projects/refactoring/ecoop09.pdf]

Lots of initiatives are being taken by tool vendors to improve refactoring tools. One such case is Net Beans where research is being carried on in this arena. The “replace method code duplicate” feature is being designed to locate selected method code repetitions and turn them in to a method call. The “generify” feature is currently developed for the transformation of non – generic code in to generic aware code. The “copy class” feature is currently in experimental stage to tap the feature of refactoring that allows to copy an existing class or interface. Likewise other features like “Inline method” which is used to inline a method, “Introduce variable” and “Clean up” are currently developed in their labs

=== '''Other Initiatives''' ===

Apart from workshops held specifically for refactoring tools, other conferences have been organized by Automated Software Engineering (ASE), International Conference on Software Engineering (ICSE), Foundations of Software Engineering (FSE) wherein papers on refactoring have been presented and awarded the best paper award.

In addition to the workshops and conferences, the weekly contest on refactoring “Refactor It! The Weekly Book Giveaway” has been started by Billy McCafferty to increase the awareness and interest among the software developers, students and other programming communities. Various groups like Software Architecture Group (SAG) at University of Illinois at Urbana-Champaign, Program Analysis and Transformation (PAT) group at IBM TJ Watson Research Center have been organized at Universities and Organizations to conduct research in refactoring tools and to improve the current generation of refactoring tools. More details about various groups and people can be found at [https://netfiles.uiuc.edu/dig/RefactoringInfo/people.html]

== External Links ==

Refactor It contest [http://devlicio.us/blogs/billy_mccafferty/archive/2006/11/13/refactor-it-the-weekly-book-giveaway.aspx]

Refactoring tool for .NET [http://submain.com/products/codeit.once.aspx]

=== '''Books''' ===

Refactoring Workbook - William.C.Wake [http://www.amazon.com/exec/obidos/tg/detail/-/0321109295]

Refactoring to Patterns - [http://industriallogic.com/xp/refactoring/]

Refactoring Databases : Evolutionary Database Design - [http://www.amazon.com/exec/obidos/ASIN/0321293533]

Professional Refactoring in Visual Basic - [http://www.amazon.com/gp/product/0470179791]

CoreJ2EE Patterns - [http://www.amazon.com/Core-J2EE-Patterns-Practices-Strategies/dp/0131422464]

== References ==

=== '''Thesis Works''' ===

William F. Opdyke, Refactoring object-oriented frameworks, University of Illinois at Urbana-Champaign, Champaign, IL, 1992 [http://portal.acm.org/citation.cfm?id=169783&dl=GUIDE&coll=GUIDE&CFID=50708246&CFTOKEN=47231553]

Refactoring as Formal Refinements- Marico Lopes Cornelio [http://dsc.upe.br/~mlc/PhDThesis/RefactoringsAsFormalRefinements.pdf]

Practical Analysis for Refactoring – Donald B Roberts, University of Illinois at Urbana-Champaign Champaign, IL, USA[http://portal.acm.org/citation.cfm?id=871251]

Refactoring Tools and Complementary Techniques - Martin Drozdz, Derrick G Kourie, Bruce W Watson, Andrew Boake Espresso Research Group, Department of Computer Science, University of Pretoria, Pretoria, South Africa 0001 [http://www2.computer.org/portal/web/csdl/doi/10.1109/AICCSA.2006.205164]

=== '''Other Papers/Conferences''' ===

William F. Opdyke and Ralph E. Johnson. Refactoring: An aid in designing application frameworks and evolving object-oriented systems. In Proceedings of Symposium on Object- Oriented Programming Emphasizing Practical Applications (SOOPPA), September 1990.

Refactoring, Reuse & Reality, Bill Opdyke, Lucent Technologies/ Bell Labs, Copyright 1999, Lucent Technologies[http://chip.cs.uiuc.edu/users/opdyke/wfo.990201.refac.html]

Why Don’t People Use Refactoring Tools? Emerson Murphy-Hill and Andrew P. Black, Portland State University [http://web.cecs.pdx.edu/~black/publications/WRT07.pdf?id=1176678&type=pdf&coll=&dl=acm&CFID=15151515&CFTOKEN=6184618]

First workshop on refactoring in conjunction with ecoop Berlin 07 [https://netfiles.uiuc.edu/dig/RefactoringWorkshop/]

Second ACM Workshop on Refactoring Tools (WRT'08)[https://netfiles.uiuc.edu/dig/RefactoringInfo/WRT08/]

Accepted papers for WRT’08 [https://agora.cs.illinois.edu/display/wrt08/Accepted+Papers]

Third ACM Workshop on Refactoring Tools (WRT'09)[https://netfiles.uiuc.edu/dig/RefactoringInfo/WRT09/]

ACM SIGSOFT 2006 / FSE 14[http://www.cs.uoregon.edu/fse-14/]

29th Int. Conference on Software Engineering® 20 - 26 May 2007[http://web4.cs.ucl.ac.uk/icse07/]

21st IEEE/ACM International Conference on Automated Software Engineering[http://ase.cs.uni-essen.de/ase/past/ase2006/]

=== '''Web''' ===

Refactoring Info[https://netfiles.uiuc.edu/dig/RefactoringInfo/index.html]

www.refactoring.com [http://www.refactoring.com/]

Refactoring at AllExperts [http://en.allexperts.com/e/r/re/refactoring.html]

Refactoring Tool - NetBeans [http://refactoring.netbeans.org/]

CSC/ECE 517 Fall 2009/wiki1a 9 DS

2009-09-09T00:34:51Z

Screenit: /* External Links */

CSC/ECE 517 Fall 2009/wiki1a 9 DS

2009-09-09T00:33:57Z

Screenit: /* Overview */

'''REFACTORING TOOLS'''

----

== Definition ==

Refactoring[http://en.wikipedia.org/wiki/Code_refactoring] is defined as the technique by which the existing body of the code is restructured by changing the inner structure and preserving its external behavior. More common refactorings that are available can be found here [http://www.refactoring.com/catalog/index.html]. The tools which are used to achieve this purpose are commonly known as Refactoring Tools.

Refactoring tools are provided as Integrated Development Environment (IDE) features currently and are available for all popular programming languages. For instance, the common IDEs that provide the refactoring tools are IBM’s Eclipse, Sun’s Netbeans and IntelliJ’s IDEA. For further information, an academic thesis “Refactoring Tools and Complementary Techniques” focuses on the survey made on the comparison of refactoring tools usage in IDEs.

Below is an example of refactoring "extract method"

Code Before refactoring

public class Refactoringjava {
public static void main(String args[]){
int a = 0,b =2,result;
result = a+b;
System.out.println("Sum =" + result);
}

Code after Refactoring

public class Refactoringjava {
public static void main(String args[]){
int a = 0,b =2,result;
result = sum(a,b);
System.out.println("Sum =" + result);
}
static int sum(int x,int y)
{
int sum = x+y;
return(sum);
}

== Overview ==
This deals with the academic underpinnings of refactoring starting from its evolution and the initiatives taken to improve the current generation of refactoring tools.In addition, this discusses the on going research initiatives to enhance the features in refactoring tools. It also throws lights up on various books, academic thesis, conferences and workshops on the topic of refactoring.

== Academic Underpinnings ==

=== '''Motivation''' ===

The first official thesis on the area of refactoring leads back to 1992 when Bill Opdyke finished his thesis on the topic "Refactoring Object-Oriented Frameworks"[http://portal.acm.org/citation.cfm?id=169783&dl=GUIDE&coll=GUIDE&CFID=50708246&CFTOKEN=47231553]. Bill Opdyke was working in Bell Laboratories developing electronic switching systems.
When he started to pursue his doctoral studies he wanted it to be related to practical business applications. That is when he narrowed down on this topic which led to the official shaping of the cloud refactoring.

The Basic motivation behind the emergence of refactoring was the software re-usability and cutting down cost involved in restructuring software for various purposes. Thus refactoring leads to software reuse in future.

Though it might appear that refactoring began in research labs it actually emerged on an ad-hoc basis when object-oriented programmers came across situations where they felt the need for change in object oriented software. Refactoring actually has its roots way back. Factoring was a key technique in Forth Language from its birth in 70’s. Absence of appropriate syntax made it not possible to extract the best use out of it. Ralph Johnson was the first person to use the name refactoring in print. Along with Bill Opdyke he published a paper on refactoring in 1990.

=== '''Etymology''' ===

The first known use of the term “refactoring” appeared in “Refactoring: An Aid in Designing Application Frameworks and Evolving Object-Oriented Systems” by Ralph Johnson and Bill Opdyke in 1990. But Refactoring as a function and as a technique, was almost certainly used before then.

=== '''More Works''' ===

Lot of work has been done on this area which includes the thesis work “Practical Analysis for refactoring” [http://portal.acm.org/citation.cfm?id=871251] by Donald Bradley Roberts. It focuses on several ways to make a refactoring tool that is both fast and reliable enough to be useful. In another thesis work “Refactoring as Formal Refinements” [http://dsc.upe.br/~mlc/PhDThesis/RefactoringsAsFormalRefinements.pdf] by Márcio Cornélio throws light on algebraic technique that presents refactoring as behavior preserving transformation. For list of other thesis works and papers refer to the References section.

=== '''Books on Refactoring''' ===

Various books are available on the topic of refactoring these days. The initial list of books includes “Refactoring: Improving the Design of Existing Code“ [http://www.amazon.com/exec/obidos/ASIN/0201485672] by Martin Flower and Refactoring to Patterns [http://www.industriallogic.com/xp/refactoring/] by Joshua Kerievsky and many more books on this topic. For listing of books on refactoring refer to the external links.

== Initiatives taken to improve current generation of refactoring tools ==

Various initiatives like conferences, workshops are conducted by Organizations like Institute of Electrical and Electronics Engineers (IEEE), Associate for Computing Machinery (ACM) to improve the current generation of refactoring tools. The first initiative taken to improve the current generation of refactoring tools was the creation of the refactoring research web portal ([http://refactoring.info]).
This research web portal includes a collection of links and articles that provide the researchers and industrial engineers an up-to-date knowledge on refactoring.

=== '''Workshops and Conferences''' ===

The second initiative taken was, organization of workshops which serve as a forum to bring researchers and tool vendors together for collaborative efforts in developing the refactoring tools. This initiative has been taken with the motive to develop the tool support for refactoring efficiently by combining the state-of-the-art research with the challenges from real-time applications. The benefits of such workshops by collaborating the researchers and tool vendors are, to develop the tools in a short period of time and to eliminate the redundant works by other researchers and tool vendors. The workshops on refactoring tools are being conducted annually at various places

The first workshop on refactoring tools was conducted on July 31st 2007 in conjunction with European Conference on Object-Oriented Programming (ECOOP) [https://netfiles.uiuc.edu/dig/RefactoringWorkshop/] at Berlin. Various papers like automated refactoring for improved cohesion, reuse based refactoring tools, Engineering reusability for software refactoring tools and others were presented and discussed. The proceedings of the first workshop can be found as a TU Berlin Technical Report, ISSN 1436-9915.

The second workshop on refactoring tools was conducted on October 19th 2008 in conjunction with Object-Oriented Programming Systems, Languages and Applications (OOPSLA) [https://netfiles.uiuc.edu/dig/RefactoringInfo/WRT08/] at Nashville, Tennessee. Various papers that were accepted and discussed were Cross Language Refactoring for Eclipse plug-ins, Tool support for refactoring functional programs, Towards a Refactoring guideline using code clone classification and others. More accepted papers at the second workshop can be found at [https://agora.cs.illinois.edu/display/wrt08/Accepted+Papers]. The interest in research in refactoring tools has increased to a greater extent that more papers were submitted and more researchers and tool vendors like JetBrains, Microsoft participated at the workshop.

The third workshop on refactoring tools is going to be held on October 25-29, 2009 in conjunction with Object-Oriented Programming Systems, Languages and Applications (OOPSLA) [https://netfiles.uiuc.edu/dig/RefactoringInfo/WRT09/] at Orlando, Florida. The papers have been invited for the topics which include language-independent transformation frameworks, language-independent analysis frameworks and analytical representations.

=== '''Ongoing Research''' ===

Refactoring in general preserves the behavior of the program during restructuring. But with the metaphor of extended language, the refactoring can be done in an efficient manner. The extended language implementation technique is all about embedding the source code into the extended language where the refactoring is easier to perform and then translating the refactored code into original language. This has been implemented on the well-known refactoring ‘Extract Method’ which showed the results that overall refactoring can be decomposed into micro-refactorings which are easy to implement and test.

Another improvement in which a tool can provide is the refactoring based on invariant preservation rather on the regular pre-condition based. The program invariants are nothing but the predicates about the objects state and their relationships which remain valid for every execution of program. There are quite a few initiatives that can be taken as part of the future research, which include the structural refactorings ‘Encapsulate Field’ or ‘Move Method’ implementation using the micro-refactoring decomposition approach. The above research is being conducted by the Programming Tools Group at University of Oxford.More information on this research can be found at [http://progtools.comlab.ox.ac.uk/projects/refactoring/ecoop09.pdf]

Lots of initiatives are being taken by tool vendors to improve refactoring tools. One such case is Net Beans where research is being carried on in this arena. The “replace method code duplicate” feature is being designed to locate selected method code repetitions and turn them in to a method call. The “generify” feature is currently developed for the transformation of non – generic code in to generic aware code. The “copy class” feature is currently in experimental stage to tap the feature of refactoring that allows to copy an existing class or interface. Likewise other features like “Inline method” which is used to inline a method, “Introduce variable” and “Clean up” are currently developed in their labs

=== '''Other Initiatives''' ===

Apart from workshops held specifically for refactoring tools, other conferences have been organized by Automated Software Engineering (ASE), International Conference on Software Engineering (ICSE), Foundations of Software Engineering (FSE) wherein papers on refactoring have been presented and awarded the best paper award.

In addition to the workshops and conferences, the weekly contest on refactoring “Refactor It! The Weekly Book Giveaway” has been started by Billy McCafferty to increase the awareness and interest among the software developers, students and other programming communities. Various groups like Software Architecture Group (SAG) at University of Illinois at Urbana-Champaign, Program Analysis and Transformation (PAT) group at IBM TJ Watson Research Center have been organized at Universities and Organizations to conduct research in refactoring tools and to improve the current generation of refactoring tools. More details about various groups and people can be found at [https://netfiles.uiuc.edu/dig/RefactoringInfo/people.html]

== External Links ==

Refactor It contest [http://devlicio.us/blogs/billy_mccafferty/archive/2006/11/13/refactor-it-the-weekly-book-giveaway.aspx]

Code It Software [http://submain.com/products/codeit.once.aspx]

=== '''Books''' ===

Refactoring Workbook - William.C.Wake [http://www.amazon.com/exec/obidos/tg/detail/-/0321109295]

Refactoring to Patterns - [http://industriallogic.com/xp/refactoring/]

Refactoring Databases : Evolutionary Database Design - [http://www.amazon.com/exec/obidos/ASIN/0321293533]

Professional Refactoring in Visual Basic - [http://www.amazon.com/gp/product/0470179791]

CoreJ2EE Patterns - [http://www.amazon.com/Core-J2EE-Patterns-Practices-Strategies/dp/0131422464]

== References ==

=== '''Thesis Works''' ===

William F. Opdyke, Refactoring object-oriented frameworks, University of Illinois at Urbana-Champaign, Champaign, IL, 1992 [http://portal.acm.org/citation.cfm?id=169783&dl=GUIDE&coll=GUIDE&CFID=50708246&CFTOKEN=47231553]

Refactoring as Formal Refinements- Marico Lopes Cornelio [http://dsc.upe.br/~mlc/PhDThesis/RefactoringsAsFormalRefinements.pdf]

Practical Analysis for Refactoring – Donald B Roberts, University of Illinois at Urbana-Champaign Champaign, IL, USA[http://portal.acm.org/citation.cfm?id=871251]

Refactoring Tools and Complementary Techniques - Martin Drozdz, Derrick G Kourie, Bruce W Watson, Andrew Boake Espresso Research Group, Department of Computer Science, University of Pretoria, Pretoria, South Africa 0001 [http://www2.computer.org/portal/web/csdl/doi/10.1109/AICCSA.2006.205164]

=== '''Other Papers/Conferences''' ===

William F. Opdyke and Ralph E. Johnson. Refactoring: An aid in designing application frameworks and evolving object-oriented systems. In Proceedings of Symposium on Object- Oriented Programming Emphasizing Practical Applications (SOOPPA), September 1990.

Refactoring, Reuse & Reality, Bill Opdyke, Lucent Technologies/ Bell Labs, Copyright 1999, Lucent Technologies[http://chip.cs.uiuc.edu/users/opdyke/wfo.990201.refac.html]

Why Don’t People Use Refactoring Tools? Emerson Murphy-Hill and Andrew P. Black, Portland State University [http://web.cecs.pdx.edu/~black/publications/WRT07.pdf?id=1176678&type=pdf&coll=&dl=acm&CFID=15151515&CFTOKEN=6184618]

First workshop on refactoring in conjunction with ecoop Berlin 07 [https://netfiles.uiuc.edu/dig/RefactoringWorkshop/]

Second ACM Workshop on Refactoring Tools (WRT'08)[https://netfiles.uiuc.edu/dig/RefactoringInfo/WRT08/]

Accepted papers for WRT’08 [https://agora.cs.illinois.edu/display/wrt08/Accepted+Papers]

Third ACM Workshop on Refactoring Tools (WRT'09)[https://netfiles.uiuc.edu/dig/RefactoringInfo/WRT09/]

ACM SIGSOFT 2006 / FSE 14[http://www.cs.uoregon.edu/fse-14/]

29th Int. Conference on Software Engineering® 20 - 26 May 2007[http://web4.cs.ucl.ac.uk/icse07/]

21st IEEE/ACM International Conference on Automated Software Engineering[http://ase.cs.uni-essen.de/ase/past/ase2006/]

=== '''Web''' ===

Refactoring Info[https://netfiles.uiuc.edu/dig/RefactoringInfo/index.html]

www.refactoring.com [http://www.refactoring.com/]

Refactoring at AllExperts [http://en.allexperts.com/e/r/re/refactoring.html]

CSC/ECE 517 Fall 2009/wiki1a 9 DS

2009-09-09T00:30:08Z

Screenit: /* Definition */

'''REFACTORING TOOLS'''

----

== Definition ==

Refactoring[http://en.wikipedia.org/wiki/Code_refactoring] is defined as the technique by which the existing body of the code is restructured by changing the inner structure and preserving its external behavior. More common refactorings that are available can be found here [http://www.refactoring.com/catalog/index.html]. The tools which are used to achieve this purpose are commonly known as Refactoring Tools.

Refactoring tools are provided as Integrated Development Environment (IDE) features currently and are available for all popular programming languages. For instance, the common IDEs that provide the refactoring tools are IBM’s Eclipse, Sun’s Netbeans and IntelliJ’s IDEA. For further information, an academic thesis “Refactoring Tools and Complementary Techniques” focuses on the survey made on the comparison of refactoring tools usage in IDEs.

Below is an example of refactoring "extract method"

Code Before refactoring

public class Refactoringjava {
public static void main(String args[]){
int a = 0,b =2,result;
result = a+b;
System.out.println("Sum =" + result);
}

Code after Refactoring

public class Refactoringjava {
public static void main(String args[]){
int a = 0,b =2,result;
result = sum(a,b);
System.out.println("Sum =" + result);
}
static int sum(int x,int y)
{
int sum = x+y;
return(sum);
}

== Overview ==
This deals with the academic underpinnings of refactoring starting from its evolution and the initiatives taken to improve the current generation of refactoring tools. It also throws lights up on various books, academic thesis, conferences and workshops on the topic of refactoring.

== Academic Underpinnings ==

=== '''Motivation''' ===

The first official thesis on the area of refactoring leads back to 1992 when Bill Opdyke finished his thesis on the topic "Refactoring Object-Oriented Frameworks"[http://portal.acm.org/citation.cfm?id=169783&dl=GUIDE&coll=GUIDE&CFID=50708246&CFTOKEN=47231553]. Bill Opdyke was working in Bell Laboratories developing electronic switching systems.
When he started to pursue his doctoral studies he wanted it to be related to practical business applications. That is when he narrowed down on this topic which led to the official shaping of the cloud refactoring.

The Basic motivation behind the emergence of refactoring was the software re-usability and cutting down cost involved in restructuring software for various purposes. Thus refactoring leads to software reuse in future.

Though it might appear that refactoring began in research labs it actually emerged on an ad-hoc basis when object-oriented programmers came across situations where they felt the need for change in object oriented software. Refactoring actually has its roots way back. Factoring was a key technique in Forth Language from its birth in 70’s. Absence of appropriate syntax made it not possible to extract the best use out of it. Ralph Johnson was the first person to use the name refactoring in print. Along with Bill Opdyke he published a paper on refactoring in 1990.

=== '''Etymology''' ===

The first known use of the term “refactoring” appeared in “Refactoring: An Aid in Designing Application Frameworks and Evolving Object-Oriented Systems” by Ralph Johnson and Bill Opdyke in 1990. But Refactoring as a function and as a technique, was almost certainly used before then.

=== '''More Works''' ===

Lot of work has been done on this area which includes the thesis work “Practical Analysis for refactoring” [http://portal.acm.org/citation.cfm?id=871251] by Donald Bradley Roberts. It focuses on several ways to make a refactoring tool that is both fast and reliable enough to be useful. In another thesis work “Refactoring as Formal Refinements” [http://dsc.upe.br/~mlc/PhDThesis/RefactoringsAsFormalRefinements.pdf] by Márcio Cornélio throws light on algebraic technique that presents refactoring as behavior preserving transformation. For list of other thesis works and papers refer to the References section.

=== '''Books on Refactoring''' ===

Various books are available on the topic of refactoring these days. The initial list of books includes “Refactoring: Improving the Design of Existing Code“ [http://www.amazon.com/exec/obidos/ASIN/0201485672] by Martin Flower and Refactoring to Patterns [http://www.industriallogic.com/xp/refactoring/] by Joshua Kerievsky and many more books on this topic. For listing of books on refactoring refer to the external links.

== Initiatives taken to improve current generation of refactoring tools ==

Various initiatives like conferences, workshops are conducted by Organizations like Institute of Electrical and Electronics Engineers (IEEE), Associate for Computing Machinery (ACM) to improve the current generation of refactoring tools. The first initiative taken to improve the current generation of refactoring tools was the creation of the refactoring research web portal ([http://refactoring.info]).
This research web portal includes a collection of links and articles that provide the researchers and industrial engineers an up-to-date knowledge on refactoring.

=== '''Workshops and Conferences''' ===

The second initiative taken was, organization of workshops which serve as a forum to bring researchers and tool vendors together for collaborative efforts in developing the refactoring tools. This initiative has been taken with the motive to develop the tool support for refactoring efficiently by combining the state-of-the-art research with the challenges from real-time applications. The benefits of such workshops by collaborating the researchers and tool vendors are, to develop the tools in a short period of time and to eliminate the redundant works by other researchers and tool vendors. The workshops on refactoring tools are being conducted annually at various places

The first workshop on refactoring tools was conducted on July 31st 2007 in conjunction with European Conference on Object-Oriented Programming (ECOOP) [https://netfiles.uiuc.edu/dig/RefactoringWorkshop/] at Berlin. Various papers like automated refactoring for improved cohesion, reuse based refactoring tools, Engineering reusability for software refactoring tools and others were presented and discussed. The proceedings of the first workshop can be found as a TU Berlin Technical Report, ISSN 1436-9915.

The second workshop on refactoring tools was conducted on October 19th 2008 in conjunction with Object-Oriented Programming Systems, Languages and Applications (OOPSLA) [https://netfiles.uiuc.edu/dig/RefactoringInfo/WRT08/] at Nashville, Tennessee. Various papers that were accepted and discussed were Cross Language Refactoring for Eclipse plug-ins, Tool support for refactoring functional programs, Towards a Refactoring guideline using code clone classification and others. More accepted papers at the second workshop can be found at [https://agora.cs.illinois.edu/display/wrt08/Accepted+Papers]. The interest in research in refactoring tools has increased to a greater extent that more papers were submitted and more researchers and tool vendors like JetBrains, Microsoft participated at the workshop.

The third workshop on refactoring tools is going to be held on October 25-29, 2009 in conjunction with Object-Oriented Programming Systems, Languages and Applications (OOPSLA) [https://netfiles.uiuc.edu/dig/RefactoringInfo/WRT09/] at Orlando, Florida. The papers have been invited for the topics which include language-independent transformation frameworks, language-independent analysis frameworks and analytical representations.

=== '''Ongoing Research''' ===

Refactoring in general preserves the behavior of the program during restructuring. But with the metaphor of extended language, the refactoring can be done in an efficient manner. The extended language implementation technique is all about embedding the source code into the extended language where the refactoring is easier to perform and then translating the refactored code into original language. This has been implemented on the well-known refactoring ‘Extract Method’ which showed the results that overall refactoring can be decomposed into micro-refactorings which are easy to implement and test.

Another improvement in which a tool can provide is the refactoring based on invariant preservation rather on the regular pre-condition based. The program invariants are nothing but the predicates about the objects state and their relationships which remain valid for every execution of program. There are quite a few initiatives that can be taken as part of the future research, which include the structural refactorings ‘Encapsulate Field’ or ‘Move Method’ implementation using the micro-refactoring decomposition approach. The above research is being conducted by the Programming Tools Group at University of Oxford.More information on this research can be found at [http://progtools.comlab.ox.ac.uk/projects/refactoring/ecoop09.pdf]

Lots of initiatives are being taken by tool vendors to improve refactoring tools. One such case is Net Beans where research is being carried on in this arena. The “replace method code duplicate” feature is being designed to locate selected method code repetitions and turn them in to a method call. The “generify” feature is currently developed for the transformation of non – generic code in to generic aware code. The “copy class” feature is currently in experimental stage to tap the feature of refactoring that allows to copy an existing class or interface. Likewise other features like “Inline method” which is used to inline a method, “Introduce variable” and “Clean up” are currently developed in their labs

=== '''Other Initiatives''' ===

Apart from workshops held specifically for refactoring tools, other conferences have been organized by Automated Software Engineering (ASE), International Conference on Software Engineering (ICSE), Foundations of Software Engineering (FSE) wherein papers on refactoring have been presented and awarded the best paper award.

In addition to the workshops and conferences, the weekly contest on refactoring “Refactor It! The Weekly Book Giveaway” has been started by Billy McCafferty to increase the awareness and interest among the software developers, students and other programming communities. Various groups like Software Architecture Group (SAG) at University of Illinois at Urbana-Champaign, Program Analysis and Transformation (PAT) group at IBM TJ Watson Research Center have been organized at Universities and Organizations to conduct research in refactoring tools and to improve the current generation of refactoring tools. More details about various groups and people can be found at [https://netfiles.uiuc.edu/dig/RefactoringInfo/people.html]

== External Links ==

Refactor It contest [http://devlicio.us/blogs/billy_mccafferty/archive/2006/11/13/refactor-it-the-weekly-book-giveaway.aspx]

Code It Software [http://submain.com/products/codeit.once.aspx]

=== '''Books''' ===

Refactoring Workbook - William.C.Wake [http://www.amazon.com/exec/obidos/tg/detail/-/0321109295]

Refactoring to Patterns - [http://industriallogic.com/xp/refactoring/]

Refactoring Databases : Evolutionary Database Design - [http://www.amazon.com/exec/obidos/ASIN/0321293533]

Professional Refactoring in Visual Basic - [http://www.amazon.com/gp/product/0470179791]

CoreJ2EE Patterns - [http://www.amazon.com/Core-J2EE-Patterns-Practices-Strategies/dp/0131422464]

== References ==

=== '''Thesis Works''' ===

William F. Opdyke, Refactoring object-oriented frameworks, University of Illinois at Urbana-Champaign, Champaign, IL, 1992 [http://portal.acm.org/citation.cfm?id=169783&dl=GUIDE&coll=GUIDE&CFID=50708246&CFTOKEN=47231553]

Refactoring as Formal Refinements- Marico Lopes Cornelio [http://dsc.upe.br/~mlc/PhDThesis/RefactoringsAsFormalRefinements.pdf]

Practical Analysis for Refactoring – Donald B Roberts, University of Illinois at Urbana-Champaign Champaign, IL, USA[http://portal.acm.org/citation.cfm?id=871251]

Refactoring Tools and Complementary Techniques - Martin Drozdz, Derrick G Kourie, Bruce W Watson, Andrew Boake Espresso Research Group, Department of Computer Science, University of Pretoria, Pretoria, South Africa 0001 [http://www2.computer.org/portal/web/csdl/doi/10.1109/AICCSA.2006.205164]

=== '''Other Papers/Conferences''' ===

William F. Opdyke and Ralph E. Johnson. Refactoring: An aid in designing application frameworks and evolving object-oriented systems. In Proceedings of Symposium on Object- Oriented Programming Emphasizing Practical Applications (SOOPPA), September 1990.

Refactoring, Reuse & Reality, Bill Opdyke, Lucent Technologies/ Bell Labs, Copyright 1999, Lucent Technologies[http://chip.cs.uiuc.edu/users/opdyke/wfo.990201.refac.html]

Why Don’t People Use Refactoring Tools? Emerson Murphy-Hill and Andrew P. Black, Portland State University [http://web.cecs.pdx.edu/~black/publications/WRT07.pdf?id=1176678&type=pdf&coll=&dl=acm&CFID=15151515&CFTOKEN=6184618]

First workshop on refactoring in conjunction with ecoop Berlin 07 [https://netfiles.uiuc.edu/dig/RefactoringWorkshop/]

Second ACM Workshop on Refactoring Tools (WRT'08)[https://netfiles.uiuc.edu/dig/RefactoringInfo/WRT08/]

Accepted papers for WRT’08 [https://agora.cs.illinois.edu/display/wrt08/Accepted+Papers]

Third ACM Workshop on Refactoring Tools (WRT'09)[https://netfiles.uiuc.edu/dig/RefactoringInfo/WRT09/]

ACM SIGSOFT 2006 / FSE 14[http://www.cs.uoregon.edu/fse-14/]

29th Int. Conference on Software Engineering® 20 - 26 May 2007[http://web4.cs.ucl.ac.uk/icse07/]

21st IEEE/ACM International Conference on Automated Software Engineering[http://ase.cs.uni-essen.de/ase/past/ase2006/]

=== '''Web''' ===

Refactoring Info[https://netfiles.uiuc.edu/dig/RefactoringInfo/index.html]

www.refactoring.com [http://www.refactoring.com/]

Refactoring at AllExperts [http://en.allexperts.com/e/r/re/refactoring.html]

CSC/ECE 517 Fall 2009/wiki1a 9 DS

2009-09-09T00:29:50Z

Screenit: /* Definition */

'''REFACTORING TOOLS'''

----

== Definition ==

Refactoring[http://en.wikipedia.org/wiki/Code_refactoring] is defined as the [[technique]] by which the existing body of the code is restructured by changing the inner structure and preserving its external behavior. More common refactorings that are available can be found here [http://www.refactoring.com/catalog/index.html]. The tools which are used to achieve this purpose are commonly known as Refactoring Tools.

Refactoring tools are provided as Integrated Development Environment (IDE) features currently and are available for all popular programming languages. For instance, the common IDEs that provide the refactoring tools are IBM’s Eclipse, Sun’s Netbeans and IntelliJ’s IDEA. For further information, an academic thesis “Refactoring Tools and Complementary Techniques” focuses on the survey made on the comparison of refactoring tools usage in IDEs.

Below is an example of refactoring "extract method"

Code Before refactoring

public class Refactoringjava {
public static void main(String args[]){
int a = 0,b =2,result;
result = a+b;
System.out.println("Sum =" + result);
}

Code after Refactoring

public class Refactoringjava {
public static void main(String args[]){
int a = 0,b =2,result;
result = sum(a,b);
System.out.println("Sum =" + result);
}
static int sum(int x,int y)
{
int sum = x+y;
return(sum);
}

== Overview ==
This deals with the academic underpinnings of refactoring starting from its evolution and the initiatives taken to improve the current generation of refactoring tools. It also throws lights up on various books, academic thesis, conferences and workshops on the topic of refactoring.

== Academic Underpinnings ==

=== '''Motivation''' ===

The first official thesis on the area of refactoring leads back to 1992 when Bill Opdyke finished his thesis on the topic "Refactoring Object-Oriented Frameworks"[http://portal.acm.org/citation.cfm?id=169783&dl=GUIDE&coll=GUIDE&CFID=50708246&CFTOKEN=47231553]. Bill Opdyke was working in Bell Laboratories developing electronic switching systems.
When he started to pursue his doctoral studies he wanted it to be related to practical business applications. That is when he narrowed down on this topic which led to the official shaping of the cloud refactoring.

The Basic motivation behind the emergence of refactoring was the software re-usability and cutting down cost involved in restructuring software for various purposes. Thus refactoring leads to software reuse in future.

Though it might appear that refactoring began in research labs it actually emerged on an ad-hoc basis when object-oriented programmers came across situations where they felt the need for change in object oriented software. Refactoring actually has its roots way back. Factoring was a key technique in Forth Language from its birth in 70’s. Absence of appropriate syntax made it not possible to extract the best use out of it. Ralph Johnson was the first person to use the name refactoring in print. Along with Bill Opdyke he published a paper on refactoring in 1990.

=== '''Etymology''' ===

The first known use of the term “refactoring” appeared in “Refactoring: An Aid in Designing Application Frameworks and Evolving Object-Oriented Systems” by Ralph Johnson and Bill Opdyke in 1990. But Refactoring as a function and as a technique, was almost certainly used before then.

=== '''More Works''' ===

Lot of work has been done on this area which includes the thesis work “Practical Analysis for refactoring” [http://portal.acm.org/citation.cfm?id=871251] by Donald Bradley Roberts. It focuses on several ways to make a refactoring tool that is both fast and reliable enough to be useful. In another thesis work “Refactoring as Formal Refinements” [http://dsc.upe.br/~mlc/PhDThesis/RefactoringsAsFormalRefinements.pdf] by Márcio Cornélio throws light on algebraic technique that presents refactoring as behavior preserving transformation. For list of other thesis works and papers refer to the References section.

=== '''Books on Refactoring''' ===

Various books are available on the topic of refactoring these days. The initial list of books includes “Refactoring: Improving the Design of Existing Code“ [http://www.amazon.com/exec/obidos/ASIN/0201485672] by Martin Flower and Refactoring to Patterns [http://www.industriallogic.com/xp/refactoring/] by Joshua Kerievsky and many more books on this topic. For listing of books on refactoring refer to the external links.

== Initiatives taken to improve current generation of refactoring tools ==

Various initiatives like conferences, workshops are conducted by Organizations like Institute of Electrical and Electronics Engineers (IEEE), Associate for Computing Machinery (ACM) to improve the current generation of refactoring tools. The first initiative taken to improve the current generation of refactoring tools was the creation of the refactoring research web portal ([http://refactoring.info]).
This research web portal includes a collection of links and articles that provide the researchers and industrial engineers an up-to-date knowledge on refactoring.

=== '''Workshops and Conferences''' ===

The second initiative taken was, organization of workshops which serve as a forum to bring researchers and tool vendors together for collaborative efforts in developing the refactoring tools. This initiative has been taken with the motive to develop the tool support for refactoring efficiently by combining the state-of-the-art research with the challenges from real-time applications. The benefits of such workshops by collaborating the researchers and tool vendors are, to develop the tools in a short period of time and to eliminate the redundant works by other researchers and tool vendors. The workshops on refactoring tools are being conducted annually at various places

The first workshop on refactoring tools was conducted on July 31st 2007 in conjunction with European Conference on Object-Oriented Programming (ECOOP) [https://netfiles.uiuc.edu/dig/RefactoringWorkshop/] at Berlin. Various papers like automated refactoring for improved cohesion, reuse based refactoring tools, Engineering reusability for software refactoring tools and others were presented and discussed. The proceedings of the first workshop can be found as a TU Berlin Technical Report, ISSN 1436-9915.

The second workshop on refactoring tools was conducted on October 19th 2008 in conjunction with Object-Oriented Programming Systems, Languages and Applications (OOPSLA) [https://netfiles.uiuc.edu/dig/RefactoringInfo/WRT08/] at Nashville, Tennessee. Various papers that were accepted and discussed were Cross Language Refactoring for Eclipse plug-ins, Tool support for refactoring functional programs, Towards a Refactoring guideline using code clone classification and others. More accepted papers at the second workshop can be found at [https://agora.cs.illinois.edu/display/wrt08/Accepted+Papers]. The interest in research in refactoring tools has increased to a greater extent that more papers were submitted and more researchers and tool vendors like JetBrains, Microsoft participated at the workshop.

The third workshop on refactoring tools is going to be held on October 25-29, 2009 in conjunction with Object-Oriented Programming Systems, Languages and Applications (OOPSLA) [https://netfiles.uiuc.edu/dig/RefactoringInfo/WRT09/] at Orlando, Florida. The papers have been invited for the topics which include language-independent transformation frameworks, language-independent analysis frameworks and analytical representations.

=== '''Ongoing Research''' ===

Refactoring in general preserves the behavior of the program during restructuring. But with the metaphor of extended language, the refactoring can be done in an efficient manner. The extended language implementation technique is all about embedding the source code into the extended language where the refactoring is easier to perform and then translating the refactored code into original language. This has been implemented on the well-known refactoring ‘Extract Method’ which showed the results that overall refactoring can be decomposed into micro-refactorings which are easy to implement and test.

Another improvement in which a tool can provide is the refactoring based on invariant preservation rather on the regular pre-condition based. The program invariants are nothing but the predicates about the objects state and their relationships which remain valid for every execution of program. There are quite a few initiatives that can be taken as part of the future research, which include the structural refactorings ‘Encapsulate Field’ or ‘Move Method’ implementation using the micro-refactoring decomposition approach. The above research is being conducted by the Programming Tools Group at University of Oxford.More information on this research can be found at [http://progtools.comlab.ox.ac.uk/projects/refactoring/ecoop09.pdf]

Lots of initiatives are being taken by tool vendors to improve refactoring tools. One such case is Net Beans where research is being carried on in this arena. The “replace method code duplicate” feature is being designed to locate selected method code repetitions and turn them in to a method call. The “generify” feature is currently developed for the transformation of non – generic code in to generic aware code. The “copy class” feature is currently in experimental stage to tap the feature of refactoring that allows to copy an existing class or interface. Likewise other features like “Inline method” which is used to inline a method, “Introduce variable” and “Clean up” are currently developed in their labs

=== '''Other Initiatives''' ===

Apart from workshops held specifically for refactoring tools, other conferences have been organized by Automated Software Engineering (ASE), International Conference on Software Engineering (ICSE), Foundations of Software Engineering (FSE) wherein papers on refactoring have been presented and awarded the best paper award.

In addition to the workshops and conferences, the weekly contest on refactoring “Refactor It! The Weekly Book Giveaway” has been started by Billy McCafferty to increase the awareness and interest among the software developers, students and other programming communities. Various groups like Software Architecture Group (SAG) at University of Illinois at Urbana-Champaign, Program Analysis and Transformation (PAT) group at IBM TJ Watson Research Center have been organized at Universities and Organizations to conduct research in refactoring tools and to improve the current generation of refactoring tools. More details about various groups and people can be found at [https://netfiles.uiuc.edu/dig/RefactoringInfo/people.html]

== External Links ==

Refactor It contest [http://devlicio.us/blogs/billy_mccafferty/archive/2006/11/13/refactor-it-the-weekly-book-giveaway.aspx]

Code It Software [http://submain.com/products/codeit.once.aspx]

=== '''Books''' ===

Refactoring Workbook - William.C.Wake [http://www.amazon.com/exec/obidos/tg/detail/-/0321109295]

Refactoring to Patterns - [http://industriallogic.com/xp/refactoring/]

Refactoring Databases : Evolutionary Database Design - [http://www.amazon.com/exec/obidos/ASIN/0321293533]

Professional Refactoring in Visual Basic - [http://www.amazon.com/gp/product/0470179791]

CoreJ2EE Patterns - [http://www.amazon.com/Core-J2EE-Patterns-Practices-Strategies/dp/0131422464]

== References ==

=== '''Thesis Works''' ===

William F. Opdyke, Refactoring object-oriented frameworks, University of Illinois at Urbana-Champaign, Champaign, IL, 1992 [http://portal.acm.org/citation.cfm?id=169783&dl=GUIDE&coll=GUIDE&CFID=50708246&CFTOKEN=47231553]

Refactoring as Formal Refinements- Marico Lopes Cornelio [http://dsc.upe.br/~mlc/PhDThesis/RefactoringsAsFormalRefinements.pdf]

Practical Analysis for Refactoring – Donald B Roberts, University of Illinois at Urbana-Champaign Champaign, IL, USA[http://portal.acm.org/citation.cfm?id=871251]

Refactoring Tools and Complementary Techniques - Martin Drozdz, Derrick G Kourie, Bruce W Watson, Andrew Boake Espresso Research Group, Department of Computer Science, University of Pretoria, Pretoria, South Africa 0001 [http://www2.computer.org/portal/web/csdl/doi/10.1109/AICCSA.2006.205164]

=== '''Other Papers/Conferences''' ===

William F. Opdyke and Ralph E. Johnson. Refactoring: An aid in designing application frameworks and evolving object-oriented systems. In Proceedings of Symposium on Object- Oriented Programming Emphasizing Practical Applications (SOOPPA), September 1990.

Refactoring, Reuse & Reality, Bill Opdyke, Lucent Technologies/ Bell Labs, Copyright 1999, Lucent Technologies[http://chip.cs.uiuc.edu/users/opdyke/wfo.990201.refac.html]

Why Don’t People Use Refactoring Tools? Emerson Murphy-Hill and Andrew P. Black, Portland State University [http://web.cecs.pdx.edu/~black/publications/WRT07.pdf?id=1176678&type=pdf&coll=&dl=acm&CFID=15151515&CFTOKEN=6184618]

First workshop on refactoring in conjunction with ecoop Berlin 07 [https://netfiles.uiuc.edu/dig/RefactoringWorkshop/]

Second ACM Workshop on Refactoring Tools (WRT'08)[https://netfiles.uiuc.edu/dig/RefactoringInfo/WRT08/]

Accepted papers for WRT’08 [https://agora.cs.illinois.edu/display/wrt08/Accepted+Papers]

Third ACM Workshop on Refactoring Tools (WRT'09)[https://netfiles.uiuc.edu/dig/RefactoringInfo/WRT09/]

ACM SIGSOFT 2006 / FSE 14[http://www.cs.uoregon.edu/fse-14/]

29th Int. Conference on Software Engineering® 20 - 26 May 2007[http://web4.cs.ucl.ac.uk/icse07/]

21st IEEE/ACM International Conference on Automated Software Engineering[http://ase.cs.uni-essen.de/ase/past/ase2006/]

=== '''Web''' ===

Refactoring Info[https://netfiles.uiuc.edu/dig/RefactoringInfo/index.html]

www.refactoring.com [http://www.refactoring.com/]

Refactoring at AllExperts [http://en.allexperts.com/e/r/re/refactoring.html]

CSC/ECE 517 Fall 2009/wiki1a 9 DS

2009-09-09T00:29:35Z

Screenit: /* Definition */

'''REFACTORING TOOLS'''

----

== Definition ==

Refactoring[http://en.wikipedia.org/wiki/Code_refactoring] is defined as the technique by which the existing body of the code is restructured by changing the inner structure and preserving its external behavior. More common refactorings that are available can be found here [http://www.refactoring.com/catalog/index.html]. The tools which are used to achieve this purpose are commonly known as Refactoring Tools.

Refactoring tools are provided as Integrated Development Environment (IDE) features currently and are available for all popular programming languages. For instance, the common IDEs that provide the refactoring tools are IBM’s Eclipse, Sun’s Netbeans and IntelliJ’s IDEA. For further information, an academic thesis “Refactoring Tools and Complementary Techniques” focuses on the survey made on the comparison of refactoring tools usage in IDEs.

Below is an example of refactoring "extract method"

Code Before refactoring

public class Refactoringjava {
public static void main(String args[]){
int a = 0,b =2,result;
result = a+b;
System.out.println("Sum =" + result);
}

Code after Refactoring

public class Refactoringjava {
public static void main(String args[]){
int a = 0,b =2,result;
result = sum(a,b);
System.out.println("Sum =" + result);
}
static int sum(int x,int y)
{
int sum = x+y;
return(sum);
}

== Overview ==
This deals with the academic underpinnings of refactoring starting from its evolution and the initiatives taken to improve the current generation of refactoring tools. It also throws lights up on various books, academic thesis, conferences and workshops on the topic of refactoring.

== Academic Underpinnings ==

=== '''Motivation''' ===

The first official thesis on the area of refactoring leads back to 1992 when Bill Opdyke finished his thesis on the topic "Refactoring Object-Oriented Frameworks"[http://portal.acm.org/citation.cfm?id=169783&dl=GUIDE&coll=GUIDE&CFID=50708246&CFTOKEN=47231553]. Bill Opdyke was working in Bell Laboratories developing electronic switching systems.
When he started to pursue his doctoral studies he wanted it to be related to practical business applications. That is when he narrowed down on this topic which led to the official shaping of the cloud refactoring.

The Basic motivation behind the emergence of refactoring was the software re-usability and cutting down cost involved in restructuring software for various purposes. Thus refactoring leads to software reuse in future.

Though it might appear that refactoring began in research labs it actually emerged on an ad-hoc basis when object-oriented programmers came across situations where they felt the need for change in object oriented software. Refactoring actually has its roots way back. Factoring was a key technique in Forth Language from its birth in 70’s. Absence of appropriate syntax made it not possible to extract the best use out of it. Ralph Johnson was the first person to use the name refactoring in print. Along with Bill Opdyke he published a paper on refactoring in 1990.

=== '''Etymology''' ===

The first known use of the term “refactoring” appeared in “Refactoring: An Aid in Designing Application Frameworks and Evolving Object-Oriented Systems” by Ralph Johnson and Bill Opdyke in 1990. But Refactoring as a function and as a technique, was almost certainly used before then.

=== '''More Works''' ===

Lot of work has been done on this area which includes the thesis work “Practical Analysis for refactoring” [http://portal.acm.org/citation.cfm?id=871251] by Donald Bradley Roberts. It focuses on several ways to make a refactoring tool that is both fast and reliable enough to be useful. In another thesis work “Refactoring as Formal Refinements” [http://dsc.upe.br/~mlc/PhDThesis/RefactoringsAsFormalRefinements.pdf] by Márcio Cornélio throws light on algebraic technique that presents refactoring as behavior preserving transformation. For list of other thesis works and papers refer to the References section.

=== '''Books on Refactoring''' ===

Various books are available on the topic of refactoring these days. The initial list of books includes “Refactoring: Improving the Design of Existing Code“ [http://www.amazon.com/exec/obidos/ASIN/0201485672] by Martin Flower and Refactoring to Patterns [http://www.industriallogic.com/xp/refactoring/] by Joshua Kerievsky and many more books on this topic. For listing of books on refactoring refer to the external links.

== Initiatives taken to improve current generation of refactoring tools ==

Various initiatives like conferences, workshops are conducted by Organizations like Institute of Electrical and Electronics Engineers (IEEE), Associate for Computing Machinery (ACM) to improve the current generation of refactoring tools. The first initiative taken to improve the current generation of refactoring tools was the creation of the refactoring research web portal ([http://refactoring.info]).
This research web portal includes a collection of links and articles that provide the researchers and industrial engineers an up-to-date knowledge on refactoring.

=== '''Workshops and Conferences''' ===

The second initiative taken was, organization of workshops which serve as a forum to bring researchers and tool vendors together for collaborative efforts in developing the refactoring tools. This initiative has been taken with the motive to develop the tool support for refactoring efficiently by combining the state-of-the-art research with the challenges from real-time applications. The benefits of such workshops by collaborating the researchers and tool vendors are, to develop the tools in a short period of time and to eliminate the redundant works by other researchers and tool vendors. The workshops on refactoring tools are being conducted annually at various places

The first workshop on refactoring tools was conducted on July 31st 2007 in conjunction with European Conference on Object-Oriented Programming (ECOOP) [https://netfiles.uiuc.edu/dig/RefactoringWorkshop/] at Berlin. Various papers like automated refactoring for improved cohesion, reuse based refactoring tools, Engineering reusability for software refactoring tools and others were presented and discussed. The proceedings of the first workshop can be found as a TU Berlin Technical Report, ISSN 1436-9915.

The second workshop on refactoring tools was conducted on October 19th 2008 in conjunction with Object-Oriented Programming Systems, Languages and Applications (OOPSLA) [https://netfiles.uiuc.edu/dig/RefactoringInfo/WRT08/] at Nashville, Tennessee. Various papers that were accepted and discussed were Cross Language Refactoring for Eclipse plug-ins, Tool support for refactoring functional programs, Towards a Refactoring guideline using code clone classification and others. More accepted papers at the second workshop can be found at [https://agora.cs.illinois.edu/display/wrt08/Accepted+Papers]. The interest in research in refactoring tools has increased to a greater extent that more papers were submitted and more researchers and tool vendors like JetBrains, Microsoft participated at the workshop.

The third workshop on refactoring tools is going to be held on October 25-29, 2009 in conjunction with Object-Oriented Programming Systems, Languages and Applications (OOPSLA) [https://netfiles.uiuc.edu/dig/RefactoringInfo/WRT09/] at Orlando, Florida. The papers have been invited for the topics which include language-independent transformation frameworks, language-independent analysis frameworks and analytical representations.

=== '''Ongoing Research''' ===

Refactoring in general preserves the behavior of the program during restructuring. But with the metaphor of extended language, the refactoring can be done in an efficient manner. The extended language implementation technique is all about embedding the source code into the extended language where the refactoring is easier to perform and then translating the refactored code into original language. This has been implemented on the well-known refactoring ‘Extract Method’ which showed the results that overall refactoring can be decomposed into micro-refactorings which are easy to implement and test.

Another improvement in which a tool can provide is the refactoring based on invariant preservation rather on the regular pre-condition based. The program invariants are nothing but the predicates about the objects state and their relationships which remain valid for every execution of program. There are quite a few initiatives that can be taken as part of the future research, which include the structural refactorings ‘Encapsulate Field’ or ‘Move Method’ implementation using the micro-refactoring decomposition approach. The above research is being conducted by the Programming Tools Group at University of Oxford.More information on this research can be found at [http://progtools.comlab.ox.ac.uk/projects/refactoring/ecoop09.pdf]

Lots of initiatives are being taken by tool vendors to improve refactoring tools. One such case is Net Beans where research is being carried on in this arena. The “replace method code duplicate” feature is being designed to locate selected method code repetitions and turn them in to a method call. The “generify” feature is currently developed for the transformation of non – generic code in to generic aware code. The “copy class” feature is currently in experimental stage to tap the feature of refactoring that allows to copy an existing class or interface. Likewise other features like “Inline method” which is used to inline a method, “Introduce variable” and “Clean up” are currently developed in their labs

=== '''Other Initiatives''' ===

Apart from workshops held specifically for refactoring tools, other conferences have been organized by Automated Software Engineering (ASE), International Conference on Software Engineering (ICSE), Foundations of Software Engineering (FSE) wherein papers on refactoring have been presented and awarded the best paper award.

In addition to the workshops and conferences, the weekly contest on refactoring “Refactor It! The Weekly Book Giveaway” has been started by Billy McCafferty to increase the awareness and interest among the software developers, students and other programming communities. Various groups like Software Architecture Group (SAG) at University of Illinois at Urbana-Champaign, Program Analysis and Transformation (PAT) group at IBM TJ Watson Research Center have been organized at Universities and Organizations to conduct research in refactoring tools and to improve the current generation of refactoring tools. More details about various groups and people can be found at [https://netfiles.uiuc.edu/dig/RefactoringInfo/people.html]

== External Links ==

Refactor It contest [http://devlicio.us/blogs/billy_mccafferty/archive/2006/11/13/refactor-it-the-weekly-book-giveaway.aspx]

Code It Software [http://submain.com/products/codeit.once.aspx]

=== '''Books''' ===

Refactoring Workbook - William.C.Wake [http://www.amazon.com/exec/obidos/tg/detail/-/0321109295]

Refactoring to Patterns - [http://industriallogic.com/xp/refactoring/]

Refactoring Databases : Evolutionary Database Design - [http://www.amazon.com/exec/obidos/ASIN/0321293533]

Professional Refactoring in Visual Basic - [http://www.amazon.com/gp/product/0470179791]

CoreJ2EE Patterns - [http://www.amazon.com/Core-J2EE-Patterns-Practices-Strategies/dp/0131422464]

== References ==

=== '''Thesis Works''' ===

William F. Opdyke, Refactoring object-oriented frameworks, University of Illinois at Urbana-Champaign, Champaign, IL, 1992 [http://portal.acm.org/citation.cfm?id=169783&dl=GUIDE&coll=GUIDE&CFID=50708246&CFTOKEN=47231553]

Refactoring as Formal Refinements- Marico Lopes Cornelio [http://dsc.upe.br/~mlc/PhDThesis/RefactoringsAsFormalRefinements.pdf]

Practical Analysis for Refactoring – Donald B Roberts, University of Illinois at Urbana-Champaign Champaign, IL, USA[http://portal.acm.org/citation.cfm?id=871251]

Refactoring Tools and Complementary Techniques - Martin Drozdz, Derrick G Kourie, Bruce W Watson, Andrew Boake Espresso Research Group, Department of Computer Science, University of Pretoria, Pretoria, South Africa 0001 [http://www2.computer.org/portal/web/csdl/doi/10.1109/AICCSA.2006.205164]

=== '''Other Papers/Conferences''' ===

William F. Opdyke and Ralph E. Johnson. Refactoring: An aid in designing application frameworks and evolving object-oriented systems. In Proceedings of Symposium on Object- Oriented Programming Emphasizing Practical Applications (SOOPPA), September 1990.

Refactoring, Reuse & Reality, Bill Opdyke, Lucent Technologies/ Bell Labs, Copyright 1999, Lucent Technologies[http://chip.cs.uiuc.edu/users/opdyke/wfo.990201.refac.html]

Why Don’t People Use Refactoring Tools? Emerson Murphy-Hill and Andrew P. Black, Portland State University [http://web.cecs.pdx.edu/~black/publications/WRT07.pdf?id=1176678&type=pdf&coll=&dl=acm&CFID=15151515&CFTOKEN=6184618]

First workshop on refactoring in conjunction with ecoop Berlin 07 [https://netfiles.uiuc.edu/dig/RefactoringWorkshop/]

Second ACM Workshop on Refactoring Tools (WRT'08)[https://netfiles.uiuc.edu/dig/RefactoringInfo/WRT08/]

Accepted papers for WRT’08 [https://agora.cs.illinois.edu/display/wrt08/Accepted+Papers]

Third ACM Workshop on Refactoring Tools (WRT'09)[https://netfiles.uiuc.edu/dig/RefactoringInfo/WRT09/]

ACM SIGSOFT 2006 / FSE 14[http://www.cs.uoregon.edu/fse-14/]

29th Int. Conference on Software Engineering® 20 - 26 May 2007[http://web4.cs.ucl.ac.uk/icse07/]

21st IEEE/ACM International Conference on Automated Software Engineering[http://ase.cs.uni-essen.de/ase/past/ase2006/]

=== '''Web''' ===

Refactoring Info[https://netfiles.uiuc.edu/dig/RefactoringInfo/index.html]

www.refactoring.com [http://www.refactoring.com/]

Refactoring at AllExperts [http://en.allexperts.com/e/r/re/refactoring.html]

CSC/ECE 517 Fall 2009/wiki1a 9 DS

2009-09-09T00:29:20Z

Screenit: /* Definition */

'''REFACTORING TOOLS'''

----

== Definition ==

Refactoring[http://en.wikipedia.org/wiki/Code_refactoring] is defined as the technique by which the existing body of the code is restructured by changing the inner structure and preserving its external behavior. More common refactorings that are available can be found here [http://www.refactoring.com/catalog/index.html]. The tools which are used to achieve this purpose are commonly known as Refactoring Tools.

Refactoring tools are provided as Integrated Development Environment (IDE) features currently and are available for all popular programming languages. For instance, the common IDEs that provide the refactoring tools are IBM’s Eclipse, Sun’s Netbeans and IntelliJ’s IDEA. For further information, an academic thesis “Refactoring Tools and Complementary Techniques” focuses on the survey made on the comparison of refactoring tools usage in IDEs.

Below is an example refactoring "extract method"

Code Before refactoring

public class Refactoringjava {
public static void main(String args[]){
int a = 0,b =2,result;
result = a+b;
System.out.println("Sum =" + result);
}

Code after Refactoring

public class Refactoringjava {
public static void main(String args[]){
int a = 0,b =2,result;
result = sum(a,b);
System.out.println("Sum =" + result);
}
static int sum(int x,int y)
{
int sum = x+y;
return(sum);
}

== Overview ==
This deals with the academic underpinnings of refactoring starting from its evolution and the initiatives taken to improve the current generation of refactoring tools. It also throws lights up on various books, academic thesis, conferences and workshops on the topic of refactoring.

== Academic Underpinnings ==

=== '''Motivation''' ===

The first official thesis on the area of refactoring leads back to 1992 when Bill Opdyke finished his thesis on the topic "Refactoring Object-Oriented Frameworks"[http://portal.acm.org/citation.cfm?id=169783&dl=GUIDE&coll=GUIDE&CFID=50708246&CFTOKEN=47231553]. Bill Opdyke was working in Bell Laboratories developing electronic switching systems.
When he started to pursue his doctoral studies he wanted it to be related to practical business applications. That is when he narrowed down on this topic which led to the official shaping of the cloud refactoring.

The Basic motivation behind the emergence of refactoring was the software re-usability and cutting down cost involved in restructuring software for various purposes. Thus refactoring leads to software reuse in future.

Though it might appear that refactoring began in research labs it actually emerged on an ad-hoc basis when object-oriented programmers came across situations where they felt the need for change in object oriented software. Refactoring actually has its roots way back. Factoring was a key technique in Forth Language from its birth in 70’s. Absence of appropriate syntax made it not possible to extract the best use out of it. Ralph Johnson was the first person to use the name refactoring in print. Along with Bill Opdyke he published a paper on refactoring in 1990.

=== '''Etymology''' ===

The first known use of the term “refactoring” appeared in “Refactoring: An Aid in Designing Application Frameworks and Evolving Object-Oriented Systems” by Ralph Johnson and Bill Opdyke in 1990. But Refactoring as a function and as a technique, was almost certainly used before then.

=== '''More Works''' ===

Lot of work has been done on this area which includes the thesis work “Practical Analysis for refactoring” [http://portal.acm.org/citation.cfm?id=871251] by Donald Bradley Roberts. It focuses on several ways to make a refactoring tool that is both fast and reliable enough to be useful. In another thesis work “Refactoring as Formal Refinements” [http://dsc.upe.br/~mlc/PhDThesis/RefactoringsAsFormalRefinements.pdf] by Márcio Cornélio throws light on algebraic technique that presents refactoring as behavior preserving transformation. For list of other thesis works and papers refer to the References section.

=== '''Books on Refactoring''' ===

Various books are available on the topic of refactoring these days. The initial list of books includes “Refactoring: Improving the Design of Existing Code“ [http://www.amazon.com/exec/obidos/ASIN/0201485672] by Martin Flower and Refactoring to Patterns [http://www.industriallogic.com/xp/refactoring/] by Joshua Kerievsky and many more books on this topic. For listing of books on refactoring refer to the external links.

== Initiatives taken to improve current generation of refactoring tools ==

Various initiatives like conferences, workshops are conducted by Organizations like Institute of Electrical and Electronics Engineers (IEEE), Associate for Computing Machinery (ACM) to improve the current generation of refactoring tools. The first initiative taken to improve the current generation of refactoring tools was the creation of the refactoring research web portal ([http://refactoring.info]).
This research web portal includes a collection of links and articles that provide the researchers and industrial engineers an up-to-date knowledge on refactoring.

=== '''Workshops and Conferences''' ===

The second initiative taken was, organization of workshops which serve as a forum to bring researchers and tool vendors together for collaborative efforts in developing the refactoring tools. This initiative has been taken with the motive to develop the tool support for refactoring efficiently by combining the state-of-the-art research with the challenges from real-time applications. The benefits of such workshops by collaborating the researchers and tool vendors are, to develop the tools in a short period of time and to eliminate the redundant works by other researchers and tool vendors. The workshops on refactoring tools are being conducted annually at various places

The first workshop on refactoring tools was conducted on July 31st 2007 in conjunction with European Conference on Object-Oriented Programming (ECOOP) [https://netfiles.uiuc.edu/dig/RefactoringWorkshop/] at Berlin. Various papers like automated refactoring for improved cohesion, reuse based refactoring tools, Engineering reusability for software refactoring tools and others were presented and discussed. The proceedings of the first workshop can be found as a TU Berlin Technical Report, ISSN 1436-9915.

The second workshop on refactoring tools was conducted on October 19th 2008 in conjunction with Object-Oriented Programming Systems, Languages and Applications (OOPSLA) [https://netfiles.uiuc.edu/dig/RefactoringInfo/WRT08/] at Nashville, Tennessee. Various papers that were accepted and discussed were Cross Language Refactoring for Eclipse plug-ins, Tool support for refactoring functional programs, Towards a Refactoring guideline using code clone classification and others. More accepted papers at the second workshop can be found at [https://agora.cs.illinois.edu/display/wrt08/Accepted+Papers]. The interest in research in refactoring tools has increased to a greater extent that more papers were submitted and more researchers and tool vendors like JetBrains, Microsoft participated at the workshop.

The third workshop on refactoring tools is going to be held on October 25-29, 2009 in conjunction with Object-Oriented Programming Systems, Languages and Applications (OOPSLA) [https://netfiles.uiuc.edu/dig/RefactoringInfo/WRT09/] at Orlando, Florida. The papers have been invited for the topics which include language-independent transformation frameworks, language-independent analysis frameworks and analytical representations.

=== '''Ongoing Research''' ===

Refactoring in general preserves the behavior of the program during restructuring. But with the metaphor of extended language, the refactoring can be done in an efficient manner. The extended language implementation technique is all about embedding the source code into the extended language where the refactoring is easier to perform and then translating the refactored code into original language. This has been implemented on the well-known refactoring ‘Extract Method’ which showed the results that overall refactoring can be decomposed into micro-refactorings which are easy to implement and test.

Another improvement in which a tool can provide is the refactoring based on invariant preservation rather on the regular pre-condition based. The program invariants are nothing but the predicates about the objects state and their relationships which remain valid for every execution of program. There are quite a few initiatives that can be taken as part of the future research, which include the structural refactorings ‘Encapsulate Field’ or ‘Move Method’ implementation using the micro-refactoring decomposition approach. The above research is being conducted by the Programming Tools Group at University of Oxford.More information on this research can be found at [http://progtools.comlab.ox.ac.uk/projects/refactoring/ecoop09.pdf]

Lots of initiatives are being taken by tool vendors to improve refactoring tools. One such case is Net Beans where research is being carried on in this arena. The “replace method code duplicate” feature is being designed to locate selected method code repetitions and turn them in to a method call. The “generify” feature is currently developed for the transformation of non – generic code in to generic aware code. The “copy class” feature is currently in experimental stage to tap the feature of refactoring that allows to copy an existing class or interface. Likewise other features like “Inline method” which is used to inline a method, “Introduce variable” and “Clean up” are currently developed in their labs

=== '''Other Initiatives''' ===

Apart from workshops held specifically for refactoring tools, other conferences have been organized by Automated Software Engineering (ASE), International Conference on Software Engineering (ICSE), Foundations of Software Engineering (FSE) wherein papers on refactoring have been presented and awarded the best paper award.

In addition to the workshops and conferences, the weekly contest on refactoring “Refactor It! The Weekly Book Giveaway” has been started by Billy McCafferty to increase the awareness and interest among the software developers, students and other programming communities. Various groups like Software Architecture Group (SAG) at University of Illinois at Urbana-Champaign, Program Analysis and Transformation (PAT) group at IBM TJ Watson Research Center have been organized at Universities and Organizations to conduct research in refactoring tools and to improve the current generation of refactoring tools. More details about various groups and people can be found at [https://netfiles.uiuc.edu/dig/RefactoringInfo/people.html]

== External Links ==

Refactor It contest [http://devlicio.us/blogs/billy_mccafferty/archive/2006/11/13/refactor-it-the-weekly-book-giveaway.aspx]

Code It Software [http://submain.com/products/codeit.once.aspx]

=== '''Books''' ===

Refactoring Workbook - William.C.Wake [http://www.amazon.com/exec/obidos/tg/detail/-/0321109295]

Refactoring to Patterns - [http://industriallogic.com/xp/refactoring/]

Refactoring Databases : Evolutionary Database Design - [http://www.amazon.com/exec/obidos/ASIN/0321293533]

Professional Refactoring in Visual Basic - [http://www.amazon.com/gp/product/0470179791]

CoreJ2EE Patterns - [http://www.amazon.com/Core-J2EE-Patterns-Practices-Strategies/dp/0131422464]

== References ==

=== '''Thesis Works''' ===

William F. Opdyke, Refactoring object-oriented frameworks, University of Illinois at Urbana-Champaign, Champaign, IL, 1992 [http://portal.acm.org/citation.cfm?id=169783&dl=GUIDE&coll=GUIDE&CFID=50708246&CFTOKEN=47231553]

Refactoring as Formal Refinements- Marico Lopes Cornelio [http://dsc.upe.br/~mlc/PhDThesis/RefactoringsAsFormalRefinements.pdf]

Practical Analysis for Refactoring – Donald B Roberts, University of Illinois at Urbana-Champaign Champaign, IL, USA[http://portal.acm.org/citation.cfm?id=871251]

Refactoring Tools and Complementary Techniques - Martin Drozdz, Derrick G Kourie, Bruce W Watson, Andrew Boake Espresso Research Group, Department of Computer Science, University of Pretoria, Pretoria, South Africa 0001 [http://www2.computer.org/portal/web/csdl/doi/10.1109/AICCSA.2006.205164]

=== '''Other Papers/Conferences''' ===

William F. Opdyke and Ralph E. Johnson. Refactoring: An aid in designing application frameworks and evolving object-oriented systems. In Proceedings of Symposium on Object- Oriented Programming Emphasizing Practical Applications (SOOPPA), September 1990.

Refactoring, Reuse & Reality, Bill Opdyke, Lucent Technologies/ Bell Labs, Copyright 1999, Lucent Technologies[http://chip.cs.uiuc.edu/users/opdyke/wfo.990201.refac.html]

Why Don’t People Use Refactoring Tools? Emerson Murphy-Hill and Andrew P. Black, Portland State University [http://web.cecs.pdx.edu/~black/publications/WRT07.pdf?id=1176678&type=pdf&coll=&dl=acm&CFID=15151515&CFTOKEN=6184618]

First workshop on refactoring in conjunction with ecoop Berlin 07 [https://netfiles.uiuc.edu/dig/RefactoringWorkshop/]

Second ACM Workshop on Refactoring Tools (WRT'08)[https://netfiles.uiuc.edu/dig/RefactoringInfo/WRT08/]

Accepted papers for WRT’08 [https://agora.cs.illinois.edu/display/wrt08/Accepted+Papers]

Third ACM Workshop on Refactoring Tools (WRT'09)[https://netfiles.uiuc.edu/dig/RefactoringInfo/WRT09/]

ACM SIGSOFT 2006 / FSE 14[http://www.cs.uoregon.edu/fse-14/]

29th Int. Conference on Software Engineering® 20 - 26 May 2007[http://web4.cs.ucl.ac.uk/icse07/]

21st IEEE/ACM International Conference on Automated Software Engineering[http://ase.cs.uni-essen.de/ase/past/ase2006/]

=== '''Web''' ===

Refactoring Info[https://netfiles.uiuc.edu/dig/RefactoringInfo/index.html]

www.refactoring.com [http://www.refactoring.com/]

Refactoring at AllExperts [http://en.allexperts.com/e/r/re/refactoring.html]

CSC/ECE 517 Fall 2009/wiki1a 9 DS

2009-09-09T00:28:31Z

Screenit: /* Definition */

'''REFACTORING TOOLS'''

----

== Definition ==

Refactoring[http://en.wikipedia.org/wiki/Code_refactoring] is defined as the technique by which the existing body of the code is restructured by changing the inner structure and preserving its external behavior. More common refactorings that are available can be found here [http://www.refactoring.com/catalog/index.html]. The tools which are used to achieve this purpose are commonly known as Refactoring Tools.

Refactoring tools are provided as Integrated Development Environment (IDE) features currently and are available for all popular programming languages. For instance, the common IDEs that provide the refactoring tools are IBM’s Eclipse, Sun’s Netbeans and IntelliJ’s IDEA. For further information, an academic thesis “Refactoring Tools and Complementary Techniques” focuses on the survey made on the comparison of refactoring tools usage in IDEs.

Code Before refactoring

public class Refactoringjava {
public static void main(String args[]){
int a = 0,b =2,result;
result = a+b;
System.out.println("Sum =" + result);
}

Code after Refactoring

public class Refactoringjava {
public static void main(String args[]){
int a = 0,b =2,result;
result = sum(a,b);
System.out.println("Sum =" + result);
}
static int sum(int x,int y)
{
int sum = x+y;
return(sum);
}

== Overview ==
This deals with the academic underpinnings of refactoring starting from its evolution and the initiatives taken to improve the current generation of refactoring tools. It also throws lights up on various books, academic thesis, conferences and workshops on the topic of refactoring.

== Academic Underpinnings ==

=== '''Motivation''' ===

The first official thesis on the area of refactoring leads back to 1992 when Bill Opdyke finished his thesis on the topic "Refactoring Object-Oriented Frameworks"[http://portal.acm.org/citation.cfm?id=169783&dl=GUIDE&coll=GUIDE&CFID=50708246&CFTOKEN=47231553]. Bill Opdyke was working in Bell Laboratories developing electronic switching systems.
When he started to pursue his doctoral studies he wanted it to be related to practical business applications. That is when he narrowed down on this topic which led to the official shaping of the cloud refactoring.

The Basic motivation behind the emergence of refactoring was the software re-usability and cutting down cost involved in restructuring software for various purposes. Thus refactoring leads to software reuse in future.

Though it might appear that refactoring began in research labs it actually emerged on an ad-hoc basis when object-oriented programmers came across situations where they felt the need for change in object oriented software. Refactoring actually has its roots way back. Factoring was a key technique in Forth Language from its birth in 70’s. Absence of appropriate syntax made it not possible to extract the best use out of it. Ralph Johnson was the first person to use the name refactoring in print. Along with Bill Opdyke he published a paper on refactoring in 1990.

=== '''Etymology''' ===

The first known use of the term “refactoring” appeared in “Refactoring: An Aid in Designing Application Frameworks and Evolving Object-Oriented Systems” by Ralph Johnson and Bill Opdyke in 1990. But Refactoring as a function and as a technique, was almost certainly used before then.

=== '''More Works''' ===

Lot of work has been done on this area which includes the thesis work “Practical Analysis for refactoring” [http://portal.acm.org/citation.cfm?id=871251] by Donald Bradley Roberts. It focuses on several ways to make a refactoring tool that is both fast and reliable enough to be useful. In another thesis work “Refactoring as Formal Refinements” [http://dsc.upe.br/~mlc/PhDThesis/RefactoringsAsFormalRefinements.pdf] by Márcio Cornélio throws light on algebraic technique that presents refactoring as behavior preserving transformation. For list of other thesis works and papers refer to the References section.

=== '''Books on Refactoring''' ===

Various books are available on the topic of refactoring these days. The initial list of books includes “Refactoring: Improving the Design of Existing Code“ [http://www.amazon.com/exec/obidos/ASIN/0201485672] by Martin Flower and Refactoring to Patterns [http://www.industriallogic.com/xp/refactoring/] by Joshua Kerievsky and many more books on this topic. For listing of books on refactoring refer to the external links.

== Initiatives taken to improve current generation of refactoring tools ==

Various initiatives like conferences, workshops are conducted by Organizations like Institute of Electrical and Electronics Engineers (IEEE), Associate for Computing Machinery (ACM) to improve the current generation of refactoring tools. The first initiative taken to improve the current generation of refactoring tools was the creation of the refactoring research web portal ([http://refactoring.info]).
This research web portal includes a collection of links and articles that provide the researchers and industrial engineers an up-to-date knowledge on refactoring.

=== '''Workshops and Conferences''' ===

The second initiative taken was, organization of workshops which serve as a forum to bring researchers and tool vendors together for collaborative efforts in developing the refactoring tools. This initiative has been taken with the motive to develop the tool support for refactoring efficiently by combining the state-of-the-art research with the challenges from real-time applications. The benefits of such workshops by collaborating the researchers and tool vendors are, to develop the tools in a short period of time and to eliminate the redundant works by other researchers and tool vendors. The workshops on refactoring tools are being conducted annually at various places

The first workshop on refactoring tools was conducted on July 31st 2007 in conjunction with European Conference on Object-Oriented Programming (ECOOP) [https://netfiles.uiuc.edu/dig/RefactoringWorkshop/] at Berlin. Various papers like automated refactoring for improved cohesion, reuse based refactoring tools, Engineering reusability for software refactoring tools and others were presented and discussed. The proceedings of the first workshop can be found as a TU Berlin Technical Report, ISSN 1436-9915.

The second workshop on refactoring tools was conducted on October 19th 2008 in conjunction with Object-Oriented Programming Systems, Languages and Applications (OOPSLA) [https://netfiles.uiuc.edu/dig/RefactoringInfo/WRT08/] at Nashville, Tennessee. Various papers that were accepted and discussed were Cross Language Refactoring for Eclipse plug-ins, Tool support for refactoring functional programs, Towards a Refactoring guideline using code clone classification and others. More accepted papers at the second workshop can be found at [https://agora.cs.illinois.edu/display/wrt08/Accepted+Papers]. The interest in research in refactoring tools has increased to a greater extent that more papers were submitted and more researchers and tool vendors like JetBrains, Microsoft participated at the workshop.

The third workshop on refactoring tools is going to be held on October 25-29, 2009 in conjunction with Object-Oriented Programming Systems, Languages and Applications (OOPSLA) [https://netfiles.uiuc.edu/dig/RefactoringInfo/WRT09/] at Orlando, Florida. The papers have been invited for the topics which include language-independent transformation frameworks, language-independent analysis frameworks and analytical representations.

=== '''Ongoing Research''' ===

Refactoring in general preserves the behavior of the program during restructuring. But with the metaphor of extended language, the refactoring can be done in an efficient manner. The extended language implementation technique is all about embedding the source code into the extended language where the refactoring is easier to perform and then translating the refactored code into original language. This has been implemented on the well-known refactoring ‘Extract Method’ which showed the results that overall refactoring can be decomposed into micro-refactorings which are easy to implement and test.

Another improvement in which a tool can provide is the refactoring based on invariant preservation rather on the regular pre-condition based. The program invariants are nothing but the predicates about the objects state and their relationships which remain valid for every execution of program. There are quite a few initiatives that can be taken as part of the future research, which include the structural refactorings ‘Encapsulate Field’ or ‘Move Method’ implementation using the micro-refactoring decomposition approach. The above research is being conducted by the Programming Tools Group at University of Oxford.More information on this research can be found at [http://progtools.comlab.ox.ac.uk/projects/refactoring/ecoop09.pdf]

Lots of initiatives are being taken by tool vendors to improve refactoring tools. One such case is Net Beans where research is being carried on in this arena. The “replace method code duplicate” feature is being designed to locate selected method code repetitions and turn them in to a method call. The “generify” feature is currently developed for the transformation of non – generic code in to generic aware code. The “copy class” feature is currently in experimental stage to tap the feature of refactoring that allows to copy an existing class or interface. Likewise other features like “Inline method” which is used to inline a method, “Introduce variable” and “Clean up” are currently developed in their labs

=== '''Other Initiatives''' ===

Apart from workshops held specifically for refactoring tools, other conferences have been organized by Automated Software Engineering (ASE), International Conference on Software Engineering (ICSE), Foundations of Software Engineering (FSE) wherein papers on refactoring have been presented and awarded the best paper award.

In addition to the workshops and conferences, the weekly contest on refactoring “Refactor It! The Weekly Book Giveaway” has been started by Billy McCafferty to increase the awareness and interest among the software developers, students and other programming communities. Various groups like Software Architecture Group (SAG) at University of Illinois at Urbana-Champaign, Program Analysis and Transformation (PAT) group at IBM TJ Watson Research Center have been organized at Universities and Organizations to conduct research in refactoring tools and to improve the current generation of refactoring tools. More details about various groups and people can be found at [https://netfiles.uiuc.edu/dig/RefactoringInfo/people.html]

== External Links ==

Refactor It contest [http://devlicio.us/blogs/billy_mccafferty/archive/2006/11/13/refactor-it-the-weekly-book-giveaway.aspx]

Code It Software [http://submain.com/products/codeit.once.aspx]

=== '''Books''' ===

Refactoring Workbook - William.C.Wake [http://www.amazon.com/exec/obidos/tg/detail/-/0321109295]

Refactoring to Patterns - [http://industriallogic.com/xp/refactoring/]

Refactoring Databases : Evolutionary Database Design - [http://www.amazon.com/exec/obidos/ASIN/0321293533]

Professional Refactoring in Visual Basic - [http://www.amazon.com/gp/product/0470179791]

CoreJ2EE Patterns - [http://www.amazon.com/Core-J2EE-Patterns-Practices-Strategies/dp/0131422464]

== References ==

=== '''Thesis Works''' ===

William F. Opdyke, Refactoring object-oriented frameworks, University of Illinois at Urbana-Champaign, Champaign, IL, 1992 [http://portal.acm.org/citation.cfm?id=169783&dl=GUIDE&coll=GUIDE&CFID=50708246&CFTOKEN=47231553]

Refactoring as Formal Refinements- Marico Lopes Cornelio [http://dsc.upe.br/~mlc/PhDThesis/RefactoringsAsFormalRefinements.pdf]

Practical Analysis for Refactoring – Donald B Roberts, University of Illinois at Urbana-Champaign Champaign, IL, USA[http://portal.acm.org/citation.cfm?id=871251]

Refactoring Tools and Complementary Techniques - Martin Drozdz, Derrick G Kourie, Bruce W Watson, Andrew Boake Espresso Research Group, Department of Computer Science, University of Pretoria, Pretoria, South Africa 0001 [http://www2.computer.org/portal/web/csdl/doi/10.1109/AICCSA.2006.205164]

=== '''Other Papers/Conferences''' ===

William F. Opdyke and Ralph E. Johnson. Refactoring: An aid in designing application frameworks and evolving object-oriented systems. In Proceedings of Symposium on Object- Oriented Programming Emphasizing Practical Applications (SOOPPA), September 1990.

Refactoring, Reuse & Reality, Bill Opdyke, Lucent Technologies/ Bell Labs, Copyright 1999, Lucent Technologies[http://chip.cs.uiuc.edu/users/opdyke/wfo.990201.refac.html]

Why Don’t People Use Refactoring Tools? Emerson Murphy-Hill and Andrew P. Black, Portland State University [http://web.cecs.pdx.edu/~black/publications/WRT07.pdf?id=1176678&type=pdf&coll=&dl=acm&CFID=15151515&CFTOKEN=6184618]

First workshop on refactoring in conjunction with ecoop Berlin 07 [https://netfiles.uiuc.edu/dig/RefactoringWorkshop/]

Second ACM Workshop on Refactoring Tools (WRT'08)[https://netfiles.uiuc.edu/dig/RefactoringInfo/WRT08/]

Accepted papers for WRT’08 [https://agora.cs.illinois.edu/display/wrt08/Accepted+Papers]

Third ACM Workshop on Refactoring Tools (WRT'09)[https://netfiles.uiuc.edu/dig/RefactoringInfo/WRT09/]

ACM SIGSOFT 2006 / FSE 14[http://www.cs.uoregon.edu/fse-14/]

29th Int. Conference on Software Engineering® 20 - 26 May 2007[http://web4.cs.ucl.ac.uk/icse07/]

21st IEEE/ACM International Conference on Automated Software Engineering[http://ase.cs.uni-essen.de/ase/past/ase2006/]

=== '''Web''' ===

Refactoring Info[https://netfiles.uiuc.edu/dig/RefactoringInfo/index.html]

www.refactoring.com [http://www.refactoring.com/]

Refactoring at AllExperts [http://en.allexperts.com/e/r/re/refactoring.html]

CSC/ECE 517 Fall 2009/wiki1a 9 DS

2009-09-09T00:23:12Z

Screenit: /* Initiatives taken to improve current generation of refactoring tools */

'''REFACTORING TOOLS'''

----

== Definition ==

Refactoring[http://en.wikipedia.org/wiki/Code_refactoring] is defined as the technique by which the existing body of the code is restructured by changing the inner structure and preserving its external behavior. More common refactorings that are available can be found here [http://www.refactoring.com/catalog/index.html]. The tools which are used to achieve this purpose are commonly known as Refactoring Tools.

Refactoring tools are provided as Integrated Development Environment (IDE) features currently and are available for all popular programming languages. For instance, the common IDEs that provide the refactoring tools are IBM’s Eclipse, Sun’s Netbeans and IntelliJ’s IDEA. For further information, an academic thesis “Refactoring Tools and Complementary Techniques” focuses on the survey made on the comparison of refactoring tools usage in IDEs.

== Overview ==
This deals with the academic underpinnings of refactoring starting from its evolution and the initiatives taken to improve the current generation of refactoring tools. It also throws lights up on various books, academic thesis, conferences and workshops on the topic of refactoring.

== Academic Underpinnings ==

=== '''Motivation''' ===

The first official thesis on the area of refactoring leads back to 1992 when Bill Opdyke finished his thesis on the topic "Refactoring Object-Oriented Frameworks"[http://portal.acm.org/citation.cfm?id=169783&dl=GUIDE&coll=GUIDE&CFID=50708246&CFTOKEN=47231553]. Bill Opdyke was working in Bell Laboratories developing electronic switching systems.
When he started to pursue his doctoral studies he wanted it to be related to practical business applications. That is when he narrowed down on this topic which led to the official shaping of the cloud refactoring.

The Basic motivation behind the emergence of refactoring was the software re-usability and cutting down cost involved in restructuring software for various purposes. Thus refactoring leads to software reuse in future.

Though it might appear that refactoring began in research labs it actually emerged on an ad-hoc basis when object-oriented programmers came across situations where they felt the need for change in object oriented software. Refactoring actually has its roots way back. Factoring was a key technique in Forth Language from its birth in 70’s. Absence of appropriate syntax made it not possible to extract the best use out of it. Ralph Johnson was the first person to use the name refactoring in print. Along with Bill Opdyke he published a paper on refactoring in 1990.

=== '''Etymology''' ===

The first known use of the term “refactoring” appeared in “Refactoring: An Aid in Designing Application Frameworks and Evolving Object-Oriented Systems” by Ralph Johnson and Bill Opdyke in 1990. But Refactoring as a function and as a technique, was almost certainly used before then.

=== '''More Works''' ===

Lot of work has been done on this area which includes the thesis work “Practical Analysis for refactoring” [http://portal.acm.org/citation.cfm?id=871251] by Donald Bradley Roberts. It focuses on several ways to make a refactoring tool that is both fast and reliable enough to be useful. In another thesis work “Refactoring as Formal Refinements” [http://dsc.upe.br/~mlc/PhDThesis/RefactoringsAsFormalRefinements.pdf] by Márcio Cornélio throws light on algebraic technique that presents refactoring as behavior preserving transformation. For list of other thesis works and papers refer to the References section.

=== '''Books on Refactoring''' ===

Various books are available on the topic of refactoring these days. The initial list of books includes “Refactoring: Improving the Design of Existing Code“ [http://www.amazon.com/exec/obidos/ASIN/0201485672] by Martin Flower and Refactoring to Patterns [http://www.industriallogic.com/xp/refactoring/] by Joshua Kerievsky and many more books on this topic. For listing of books on refactoring refer to the external links.

== Initiatives taken to improve current generation of refactoring tools ==

Various initiatives like conferences, workshops are conducted by Organizations like Institute of Electrical and Electronics Engineers (IEEE), Associate for Computing Machinery (ACM) to improve the current generation of refactoring tools. The first initiative taken to improve the current generation of refactoring tools was the creation of the refactoring research web portal ([http://refactoring.info]).
This research web portal includes a collection of links and articles that provide the researchers and industrial engineers an up-to-date knowledge on refactoring.

=== '''Workshops and Conferences''' ===

The second initiative taken was, organization of workshops which serve as a forum to bring researchers and tool vendors together for collaborative efforts in developing the refactoring tools. This initiative has been taken with the motive to develop the tool support for refactoring efficiently by combining the state-of-the-art research with the challenges from real-time applications. The benefits of such workshops by collaborating the researchers and tool vendors are, to develop the tools in a short period of time and to eliminate the redundant works by other researchers and tool vendors. The workshops on refactoring tools are being conducted annually at various places

The first workshop on refactoring tools was conducted on July 31st 2007 in conjunction with European Conference on Object-Oriented Programming (ECOOP) [https://netfiles.uiuc.edu/dig/RefactoringWorkshop/] at Berlin. Various papers like automated refactoring for improved cohesion, reuse based refactoring tools, Engineering reusability for software refactoring tools and others were presented and discussed. The proceedings of the first workshop can be found as a TU Berlin Technical Report, ISSN 1436-9915.

The second workshop on refactoring tools was conducted on October 19th 2008 in conjunction with Object-Oriented Programming Systems, Languages and Applications (OOPSLA) [https://netfiles.uiuc.edu/dig/RefactoringInfo/WRT08/] at Nashville, Tennessee. Various papers that were accepted and discussed were Cross Language Refactoring for Eclipse plug-ins, Tool support for refactoring functional programs, Towards a Refactoring guideline using code clone classification and others. More accepted papers at the second workshop can be found at [https://agora.cs.illinois.edu/display/wrt08/Accepted+Papers]. The interest in research in refactoring tools has increased to a greater extent that more papers were submitted and more researchers and tool vendors like JetBrains, Microsoft participated at the workshop.

The third workshop on refactoring tools is going to be held on October 25-29, 2009 in conjunction with Object-Oriented Programming Systems, Languages and Applications (OOPSLA) [https://netfiles.uiuc.edu/dig/RefactoringInfo/WRT09/] at Orlando, Florida. The papers have been invited for the topics which include language-independent transformation frameworks, language-independent analysis frameworks and analytical representations.

=== '''Ongoing Research''' ===

Refactoring in general preserves the behavior of the program during restructuring. But with the metaphor of extended language, the refactoring can be done in an efficient manner. The extended language implementation technique is all about embedding the source code into the extended language where the refactoring is easier to perform and then translating the refactored code into original language. This has been implemented on the well-known refactoring ‘Extract Method’ which showed the results that overall refactoring can be decomposed into micro-refactorings which are easy to implement and test.

Another improvement in which a tool can provide is the refactoring based on invariant preservation rather on the regular pre-condition based. The program invariants are nothing but the predicates about the objects state and their relationships which remain valid for every execution of program. There are quite a few initiatives that can be taken as part of the future research, which include the structural refactorings ‘Encapsulate Field’ or ‘Move Method’ implementation using the micro-refactoring decomposition approach. The above research is being conducted by the Programming Tools Group at University of Oxford.More information on this research can be found at [http://progtools.comlab.ox.ac.uk/projects/refactoring/ecoop09.pdf]

Lots of initiatives are being taken by tool vendors to improve refactoring tools. One such case is Net Beans where research is being carried on in this arena. The “replace method code duplicate” feature is being designed to locate selected method code repetitions and turn them in to a method call. The “generify” feature is currently developed for the transformation of non – generic code in to generic aware code. The “copy class” feature is currently in experimental stage to tap the feature of refactoring that allows to copy an existing class or interface. Likewise other features like “Inline method” which is used to inline a method, “Introduce variable” and “Clean up” are currently developed in their labs

=== '''Other Initiatives''' ===

Apart from workshops held specifically for refactoring tools, other conferences have been organized by Automated Software Engineering (ASE), International Conference on Software Engineering (ICSE), Foundations of Software Engineering (FSE) wherein papers on refactoring have been presented and awarded the best paper award.

In addition to the workshops and conferences, the weekly contest on refactoring “Refactor It! The Weekly Book Giveaway” has been started by Billy McCafferty to increase the awareness and interest among the software developers, students and other programming communities. Various groups like Software Architecture Group (SAG) at University of Illinois at Urbana-Champaign, Program Analysis and Transformation (PAT) group at IBM TJ Watson Research Center have been organized at Universities and Organizations to conduct research in refactoring tools and to improve the current generation of refactoring tools. More details about various groups and people can be found at [https://netfiles.uiuc.edu/dig/RefactoringInfo/people.html]

== External Links ==

Refactor It contest [http://devlicio.us/blogs/billy_mccafferty/archive/2006/11/13/refactor-it-the-weekly-book-giveaway.aspx]

Code It Software [http://submain.com/products/codeit.once.aspx]

=== '''Books''' ===

Refactoring Workbook - William.C.Wake [http://www.amazon.com/exec/obidos/tg/detail/-/0321109295]

Refactoring to Patterns - [http://industriallogic.com/xp/refactoring/]

Refactoring Databases : Evolutionary Database Design - [http://www.amazon.com/exec/obidos/ASIN/0321293533]

Professional Refactoring in Visual Basic - [http://www.amazon.com/gp/product/0470179791]

CoreJ2EE Patterns - [http://www.amazon.com/Core-J2EE-Patterns-Practices-Strategies/dp/0131422464]

== References ==

=== '''Thesis Works''' ===

William F. Opdyke, Refactoring object-oriented frameworks, University of Illinois at Urbana-Champaign, Champaign, IL, 1992 [http://portal.acm.org/citation.cfm?id=169783&dl=GUIDE&coll=GUIDE&CFID=50708246&CFTOKEN=47231553]

Refactoring as Formal Refinements- Marico Lopes Cornelio [http://dsc.upe.br/~mlc/PhDThesis/RefactoringsAsFormalRefinements.pdf]

Practical Analysis for Refactoring – Donald B Roberts, University of Illinois at Urbana-Champaign Champaign, IL, USA[http://portal.acm.org/citation.cfm?id=871251]

Refactoring Tools and Complementary Techniques - Martin Drozdz, Derrick G Kourie, Bruce W Watson, Andrew Boake Espresso Research Group, Department of Computer Science, University of Pretoria, Pretoria, South Africa 0001 [http://www2.computer.org/portal/web/csdl/doi/10.1109/AICCSA.2006.205164]

=== '''Other Papers/Conferences''' ===

William F. Opdyke and Ralph E. Johnson. Refactoring: An aid in designing application frameworks and evolving object-oriented systems. In Proceedings of Symposium on Object- Oriented Programming Emphasizing Practical Applications (SOOPPA), September 1990.

Refactoring, Reuse & Reality, Bill Opdyke, Lucent Technologies/ Bell Labs, Copyright 1999, Lucent Technologies[http://chip.cs.uiuc.edu/users/opdyke/wfo.990201.refac.html]

Why Don’t People Use Refactoring Tools? Emerson Murphy-Hill and Andrew P. Black, Portland State University [http://web.cecs.pdx.edu/~black/publications/WRT07.pdf?id=1176678&type=pdf&coll=&dl=acm&CFID=15151515&CFTOKEN=6184618]

First workshop on refactoring in conjunction with ecoop Berlin 07 [https://netfiles.uiuc.edu/dig/RefactoringWorkshop/]

Second ACM Workshop on Refactoring Tools (WRT'08)[https://netfiles.uiuc.edu/dig/RefactoringInfo/WRT08/]

Accepted papers for WRT’08 [https://agora.cs.illinois.edu/display/wrt08/Accepted+Papers]

Third ACM Workshop on Refactoring Tools (WRT'09)[https://netfiles.uiuc.edu/dig/RefactoringInfo/WRT09/]

ACM SIGSOFT 2006 / FSE 14[http://www.cs.uoregon.edu/fse-14/]

29th Int. Conference on Software Engineering® 20 - 26 May 2007[http://web4.cs.ucl.ac.uk/icse07/]

21st IEEE/ACM International Conference on Automated Software Engineering[http://ase.cs.uni-essen.de/ase/past/ase2006/]

=== '''Web''' ===

Refactoring Info[https://netfiles.uiuc.edu/dig/RefactoringInfo/index.html]

www.refactoring.com [http://www.refactoring.com/]

Refactoring at AllExperts [http://en.allexperts.com/e/r/re/refactoring.html]

CSC/ECE 517 Fall 2009/wiki1a 9 DS

2009-09-08T02:22:42Z

Screenit: /* Definition */

'''REFACTORING TOOLS'''

----

== Definition ==

Refactoring[http://en.wikipedia.org/wiki/Code_refactoring] is defined as the technique by which the existing body of the code is restructured by changing the inner structure and preserving its external behavior. More common refactorings that are available can be found here [http://www.refactoring.com/catalog/index.html]. The tools which are used to achieve this purpose are commonly known as Refactoring Tools.

Refactoring tools are provided as Integrated Development Environment (IDE) features currently and are available for all popular programming languages. For instance, the common IDEs that provide the refactoring tools are IBM’s Eclipse, Sun’s Netbeans and IntelliJ’s IDEA. For further information, an academic thesis “Refactoring Tools and Complementary Techniques” focuses on the survey made on the comparison of refactoring tools usage in IDEs.

== Overview ==
This deals with the academic underpinnings of refactoring starting from its evolution and the initiatives taken to improve the current generation of refactoring tools. It also throws lights up on various books, academic thesis, conferences and workshops on the topic of refactoring.

== Academic Underpinnings ==

=== '''Motivation''' ===

The first official thesis on the area of refactoring leads back to 1992 when Bill Opdyke finished his thesis on the topic "Refactoring Object-Oriented Frameworks"[http://portal.acm.org/citation.cfm?id=169783&dl=GUIDE&coll=GUIDE&CFID=50708246&CFTOKEN=47231553]. Bill Opdyke was working in Bell Laboratories developing electronic switching systems.
When he started to pursue his doctoral studies he wanted it to be related to practical business applications. That is when he narrowed down on this topic which led to the official shaping of the cloud refactoring.

The Basic motivation behind the emergence of refactoring was the software re-usability and cutting down cost involved in restructuring software for various purposes. Thus refactoring leads to software reuse in future.

Though it might appear that refactoring began in research labs it actually emerged on an ad-hoc basis when object-oriented programmers came across situations where they felt the need for change in object oriented software. Refactoring actually has its roots way back. Factoring was a key technique in Forth Language from its birth in 70’s. Absence of appropriate syntax made it not possible to extract the best use out of it. Ralph Johnson was the first person to use the name refactoring in print. Along with Bill Opdyke he published a paper on refactoring in 1990.

=== '''Etymology''' ===

The first known use of the term “refactoring” appeared in “Refactoring: An Aid in Designing Application Frameworks and Evolving Object-Oriented Systems” by Ralph Johnson and Bill Opdyke in 1990. But Refactoring as a function and as a technique, was almost certainly used before then.

=== '''More Works''' ===

Lot of work has been done on this area which includes the thesis work “Practical Analysis for refactoring” [http://portal.acm.org/citation.cfm?id=871251] by Donald Bradley Roberts. It focuses on several ways to make a refactoring tool that is both fast and reliable enough to be useful. In another thesis work “Refactoring as Formal Refinements” [http://dsc.upe.br/~mlc/PhDThesis/RefactoringsAsFormalRefinements.pdf] by Márcio Cornélio throws light on algebraic technique that presents refactoring as behavior preserving transformation. For list of other thesis works and papers refer to the References section.

=== '''Books on Refactoring''' ===

Various books are available on the topic of refactoring these days. The initial list of books includes “Refactoring: Improving the Design of Existing Code“ [http://www.amazon.com/exec/obidos/ASIN/0201485672] by Martin Flower and Refactoring to Patterns [http://www.industriallogic.com/xp/refactoring/] by Joshua Kerievsky and many more books on this topic. For listing of books on refactoring refer to the external links.

== Initiatives taken to improve current generation of refactoring tools ==

=== '''Web Portal''' ===

Various initiatives like conferences, workshops are conducted by Organizations like Institute of Electrical and Electronics Engineers (IEEE), Associate for Computing Machinery (ACM) to improve the current generation of refactoring tools. The first initiative taken to improve the current generation of refactoring tools was the creation of the refactoring research web portal ([http://refactoring.info]).
This research web portal includes a collection of links and articles that provide the researchers and industrial engineers an up-to-date knowledge on refactoring.

=== '''Workshops and Conferences''' ===

The second initiative taken was, organization of workshops which serve as a forum to bring researchers and tool vendors together for collaborative efforts in developing the refactoring tools. This initiative has been taken with the motive to develop the tool support for refactoring efficiently by combining the state-of-the-art research with the challenges from real-time applications. The benefits of such workshops by collaborating the researchers and tool vendors are, to develop the tools in a short period of time and to eliminate the redundant works by other researchers and tool vendors. The workshops on refactoring tools are being conducted annually at various places

The first workshop on refactoring tools was conducted on July 31st 2007 in conjunction with European Conference on Object-Oriented Programming (ECOOP) [https://netfiles.uiuc.edu/dig/RefactoringWorkshop/] at Berlin. Various papers like automated refactoring for improved cohesion, reuse based refactoring tools, Engineering reusability for software refactoring tools and others were presented and discussed. The proceedings of the first workshop can be found as a TU Berlin Technical Report, ISSN 1436-9915.

The second workshop on refactoring tools was conducted on October 19th 2008 in conjunction with Object-Oriented Programming Systems, Languages and Applications (OOPSLA) [https://netfiles.uiuc.edu/dig/RefactoringInfo/WRT08/] at Nashville, Tennessee. Various papers that were accepted and discussed were Cross Language Refactoring for Eclipse plug-ins, Tool support for refactoring functional programs, Towards a Refactoring guideline using code clone classification and others. More accepted papers at the second workshop can be found at [https://agora.cs.illinois.edu/display/wrt08/Accepted+Papers]. The interest in research in refactoring tools has increased to a greater extent that more papers were submitted and more researchers and tool vendors like JetBrains, Microsoft participated at the workshop.

The third workshop on refactoring tools is going to be held on October 25-29, 2009 in conjunction with Object-Oriented Programming Systems, Languages and Applications (OOPSLA) [https://netfiles.uiuc.edu/dig/RefactoringInfo/WRT09/] at Orlando, Florida. The papers have been invited for the topics which include language-independent transformation frameworks, language-independent analysis frameworks and analytical representations.

=== '''Other Initiatives''' ===

Apart from workshops held specifically for refactoring tools, other conferences have been organized by Automated Software Engineering (ASE), International Conference on Software Engineering (ICSE), Foundations of Software Engineering (FSE) wherein papers on refactoring have been presented and awarded the best paper award.

In addition to the workshops and conferences, the weekly contest on refactoring “Refactor It! The Weekly Book Giveaway” has been started by Billy McCafferty to increase the awareness and interest among the software developers, students and other programming communities. Various groups like Software Architecture Group (SAG) at University of Illinois at Urbana-Champaign, Program Analysis and Transformation (PAT) group at IBM TJ Watson Research Center have been organized at Universities and Organizations to conduct research in refactoring tools and to improve the current generation of refactoring tools. More details about various groups and people can be found at [https://netfiles.uiuc.edu/dig/RefactoringInfo/people.html]

== External Links ==

Refactor It contest [http://devlicio.us/blogs/billy_mccafferty/archive/2006/11/13/refactor-it-the-weekly-book-giveaway.aspx]

Code It Software [http://submain.com/products/codeit.once.aspx]

=== '''Books''' ===

Refactoring Workbook - William.C.Wake [http://www.amazon.com/exec/obidos/tg/detail/-/0321109295]

Refactoring to Patterns - [http://industriallogic.com/xp/refactoring/]

Refactoring Databases : Evolutionary Database Design - [http://www.amazon.com/exec/obidos/ASIN/0321293533]

Professional Refactoring in Visual Basic - [http://www.amazon.com/gp/product/0470179791]

CoreJ2EE Patterns - [http://www.amazon.com/Core-J2EE-Patterns-Practices-Strategies/dp/0131422464]

== References ==

=== '''Thesis Works''' ===

William F. Opdyke, Refactoring object-oriented frameworks, University of Illinois at Urbana-Champaign, Champaign, IL, 1992 [http://portal.acm.org/citation.cfm?id=169783&dl=GUIDE&coll=GUIDE&CFID=50708246&CFTOKEN=47231553]

Refactoring as Formal Refinements- Marico Lopes Cornelio [http://dsc.upe.br/~mlc/PhDThesis/RefactoringsAsFormalRefinements.pdf]

Practical Analysis for Refactoring – Donald B Roberts, University of Illinois at Urbana-Champaign Champaign, IL, USA[http://portal.acm.org/citation.cfm?id=871251]

Refactoring Tools and Complementary Techniques - Martin Drozdz, Derrick G Kourie, Bruce W Watson, Andrew Boake Espresso Research Group, Department of Computer Science, University of Pretoria, Pretoria, South Africa 0001 [http://www2.computer.org/portal/web/csdl/doi/10.1109/AICCSA.2006.205164]

=== '''Other Papers/Conferences''' ===

William F. Opdyke and Ralph E. Johnson. Refactoring: An aid in designing application frameworks and evolving object-oriented systems. In Proceedings of Symposium on Object- Oriented Programming Emphasizing Practical Applications (SOOPPA), September 1990.

Refactoring, Reuse & Reality, Bill Opdyke, Lucent Technologies/ Bell Labs, Copyright 1999, Lucent Technologies[http://chip.cs.uiuc.edu/users/opdyke/wfo.990201.refac.html]

Why Don’t People Use Refactoring Tools? Emerson Murphy-Hill and Andrew P. Black, Portland State University [http://web.cecs.pdx.edu/~black/publications/WRT07.pdf?id=1176678&type=pdf&coll=&dl=acm&CFID=15151515&CFTOKEN=6184618]

First workshop on refactoring in conjunction with ecoop Berlin 07 [https://netfiles.uiuc.edu/dig/RefactoringWorkshop/]

Second ACM Workshop on Refactoring Tools (WRT'08)[https://netfiles.uiuc.edu/dig/RefactoringInfo/WRT08/]

Accepted papers for WRT’08 [https://agora.cs.illinois.edu/display/wrt08/Accepted+Papers]

Third ACM Workshop on Refactoring Tools (WRT'09)[https://netfiles.uiuc.edu/dig/RefactoringInfo/WRT09/]

ACM SIGSOFT 2006 / FSE 14[http://www.cs.uoregon.edu/fse-14/]

29th Int. Conference on Software Engineering® 20 - 26 May 2007[http://web4.cs.ucl.ac.uk/icse07/]

21st IEEE/ACM International Conference on Automated Software Engineering[http://ase.cs.uni-essen.de/ase/past/ase2006/]

=== '''Web''' ===

Refactoring Info[https://netfiles.uiuc.edu/dig/RefactoringInfo/index.html]

www.refactoring.com [http://www.refactoring.com/]

Refactoring at AllExperts [http://en.allexperts.com/e/r/re/refactoring.html]

CSC/ECE 517 Fall 2009/wiki1a 9 DS

2009-09-08T02:13:49Z

Screenit: /* '''Other Papers/Conferences''' */

'''REFACTORING TOOLS'''

----

== Definition ==

Refactoring[http://en.wikipedia.org/wiki/Code_refactoring] is defined as the technique by which the existing body of the code is restructured by changing the inner structure and preserving its external behavior. The tools which are used to achieve this purpose are commonly known as Refactoring Tools.

Refactoring tools are provided as Integrated Development Environment (IDE) features currently and are available for all popular programming languages. For instance, the common IDEs that provide the refactoring tools are IBM’s Eclipse, Sun’s Netbeans and IntelliJ’s IDEA. For further information, an academic thesis “Refactoring Tools and Complementary Techniques” focuses on the survey made on the comparison of refactoring tools usage in IDEs.

== Overview ==
This deals with the academic underpinnings of refactoring starting from its evolution and the initiatives taken to improve the current generation of refactoring tools. It also throws lights up on various books, academic thesis, conferences and workshops on the topic of refactoring.

== Academic Underpinnings ==

=== '''Motivation''' ===

The first official thesis on the area of refactoring leads back to 1992 when Bill Opdyke finished his thesis on the topic "Refactoring Object-Oriented Frameworks"[http://portal.acm.org/citation.cfm?id=169783&dl=GUIDE&coll=GUIDE&CFID=50708246&CFTOKEN=47231553]. Bill Opdyke was working in Bell Laboratories developing electronic switching systems.
When he started to pursue his doctoral studies he wanted it to be related to practical business applications. That is when he narrowed down on this topic which led to the official shaping of the cloud refactoring.

The Basic motivation behind the emergence of refactoring was the software re-usability and cutting down cost involved in restructuring software for various purposes. Thus refactoring leads to software reuse in future.

Though it might appear that refactoring began in research labs it actually emerged on an ad-hoc basis when object-oriented programmers came across situations where they felt the need for change in object oriented software. Refactoring actually has its roots way back. Factoring was a key technique in Forth Language from its birth in 70’s. Absence of appropriate syntax made it not possible to extract the best use out of it. Ralph Johnson was the first person to use the name refactoring in print. Along with Bill Opdyke he published a paper on refactoring in 1990.

=== '''Etymology''' ===

The first known use of the term “refactoring” appeared in “Refactoring: An Aid in Designing Application Frameworks and Evolving Object-Oriented Systems” by Ralph Johnson and Bill Opdyke in 1990. But Refactoring as a function and as a technique, was almost certainly used before then.

=== '''More Works''' ===

Lot of work has been done on this area which includes the thesis work “Practical Analysis for refactoring” [http://portal.acm.org/citation.cfm?id=871251] by Donald Bradley Roberts. It focuses on several ways to make a refactoring tool that is both fast and reliable enough to be useful. In another thesis work “Refactoring as Formal Refinements” [http://dsc.upe.br/~mlc/PhDThesis/RefactoringsAsFormalRefinements.pdf] by Márcio Cornélio throws light on algebraic technique that presents refactoring as behavior preserving transformation. For list of other thesis works and papers refer to the References section.

=== '''Books on Refactoring''' ===

Various books are available on the topic of refactoring these days. The initial list of books includes “Refactoring: Improving the Design of Existing Code“ [http://www.amazon.com/exec/obidos/ASIN/0201485672] by Martin Flower and Refactoring to Patterns [http://www.industriallogic.com/xp/refactoring/] by Joshua Kerievsky and many more books on this topic. For listing of books on refactoring refer to the external links.

== Initiatives taken to improve current generation of refactoring tools ==

=== '''Web Portal''' ===

Various initiatives like conferences, workshops are conducted by Organizations like Institute of Electrical and Electronics Engineers (IEEE), Associate for Computing Machinery (ACM) to improve the current generation of refactoring tools. The first initiative taken to improve the current generation of refactoring tools was the creation of the refactoring research web portal ([http://refactoring.info]).
This research web portal includes a collection of links and articles that provide the researchers and industrial engineers an up-to-date knowledge on refactoring.

=== '''Workshops and Conferences''' ===

The second initiative taken was, organization of workshops which serve as a forum to bring researchers and tool vendors together for collaborative efforts in developing the refactoring tools. This initiative has been taken with the motive to develop the tool support for refactoring efficiently by combining the state-of-the-art research with the challenges from real-time applications. The benefits of such workshops by collaborating the researchers and tool vendors are, to develop the tools in a short period of time and to eliminate the redundant works by other researchers and tool vendors. The workshops on refactoring tools are being conducted annually at various places

The first workshop on refactoring tools was conducted on July 31st 2007 in conjunction with European Conference on Object-Oriented Programming (ECOOP) [https://netfiles.uiuc.edu/dig/RefactoringWorkshop/] at Berlin. Various papers like automated refactoring for improved cohesion, reuse based refactoring tools, Engineering reusability for software refactoring tools and others were presented and discussed. The proceedings of the first workshop can be found as a TU Berlin Technical Report, ISSN 1436-9915.

The second workshop on refactoring tools was conducted on October 19th 2008 in conjunction with Object-Oriented Programming Systems, Languages and Applications (OOPSLA) [https://netfiles.uiuc.edu/dig/RefactoringInfo/WRT08/] at Nashville, Tennessee. Various papers that were accepted and discussed were Cross Language Refactoring for Eclipse plug-ins, Tool support for refactoring functional programs, Towards a Refactoring guideline using code clone classification and others. More accepted papers at the second workshop can be found at [https://agora.cs.illinois.edu/display/wrt08/Accepted+Papers]. The interest in research in refactoring tools has increased to a greater extent that more papers were submitted and more researchers and tool vendors like JetBrains, Microsoft participated at the workshop.

The third workshop on refactoring tools is going to be held on October 25-29, 2009 in conjunction with Object-Oriented Programming Systems, Languages and Applications (OOPSLA) [https://netfiles.uiuc.edu/dig/RefactoringInfo/WRT09/] at Orlando, Florida. The papers have been invited for the topics which include language-independent transformation frameworks, language-independent analysis frameworks and analytical representations.

=== '''Other Initiatives''' ===

Apart from workshops held specifically for refactoring tools, other conferences have been organized by Automated Software Engineering (ASE), International Conference on Software Engineering (ICSE), Foundations of Software Engineering (FSE) wherein papers on refactoring have been presented and awarded the best paper award.

In addition to the workshops and conferences, the weekly contest on refactoring “Refactor It! The Weekly Book Giveaway” has been started by Billy McCafferty to increase the awareness and interest among the software developers, students and other programming communities. Various groups like Software Architecture Group (SAG) at University of Illinois at Urbana-Champaign, Program Analysis and Transformation (PAT) group at IBM TJ Watson Research Center have been organized at Universities and Organizations to conduct research in refactoring tools and to improve the current generation of refactoring tools. More details about various groups and people can be found at [https://netfiles.uiuc.edu/dig/RefactoringInfo/people.html]

== External Links ==

Refactor It contest [http://devlicio.us/blogs/billy_mccafferty/archive/2006/11/13/refactor-it-the-weekly-book-giveaway.aspx]

Code It Software [http://submain.com/products/codeit.once.aspx]

=== '''Books''' ===

Refactoring Workbook - William.C.Wake [http://www.amazon.com/exec/obidos/tg/detail/-/0321109295]

Refactoring to Patterns - [http://industriallogic.com/xp/refactoring/]

Refactoring Databases : Evolutionary Database Design - [http://www.amazon.com/exec/obidos/ASIN/0321293533]

Professional Refactoring in Visual Basic - [http://www.amazon.com/gp/product/0470179791]

CoreJ2EE Patterns - [http://www.amazon.com/Core-J2EE-Patterns-Practices-Strategies/dp/0131422464]

== References ==

=== '''Thesis Works''' ===

William F. Opdyke, Refactoring object-oriented frameworks, University of Illinois at Urbana-Champaign, Champaign, IL, 1992 [http://portal.acm.org/citation.cfm?id=169783&dl=GUIDE&coll=GUIDE&CFID=50708246&CFTOKEN=47231553]

Refactoring as Formal Refinements- Marico Lopes Cornelio [http://dsc.upe.br/~mlc/PhDThesis/RefactoringsAsFormalRefinements.pdf]

Practical Analysis for Refactoring – Donald B Roberts, University of Illinois at Urbana-Champaign Champaign, IL, USA[http://portal.acm.org/citation.cfm?id=871251]

Refactoring Tools and Complementary Techniques - Martin Drozdz, Derrick G Kourie, Bruce W Watson, Andrew Boake Espresso Research Group, Department of Computer Science, University of Pretoria, Pretoria, South Africa 0001 [http://www2.computer.org/portal/web/csdl/doi/10.1109/AICCSA.2006.205164]

=== '''Other Papers/Conferences''' ===

William F. Opdyke and Ralph E. Johnson. Refactoring: An aid in designing application frameworks and evolving object-oriented systems. In Proceedings of Symposium on Object- Oriented Programming Emphasizing Practical Applications (SOOPPA), September 1990.

Refactoring, Reuse & Reality, Bill Opdyke, Lucent Technologies/ Bell Labs, Copyright 1999, Lucent Technologies[http://chip.cs.uiuc.edu/users/opdyke/wfo.990201.refac.html]

Why Don’t People Use Refactoring Tools? Emerson Murphy-Hill and Andrew P. Black, Portland State University [http://web.cecs.pdx.edu/~black/publications/WRT07.pdf?id=1176678&type=pdf&coll=&dl=acm&CFID=15151515&CFTOKEN=6184618]

First workshop on refactoring in conjunction with ecoop Berlin 07 [https://netfiles.uiuc.edu/dig/RefactoringWorkshop/]

Second ACM Workshop on Refactoring Tools (WRT'08)[https://netfiles.uiuc.edu/dig/RefactoringInfo/WRT08/]

Accepted papers for WRT’08 [https://agora.cs.illinois.edu/display/wrt08/Accepted+Papers]

Third ACM Workshop on Refactoring Tools (WRT'09)[https://netfiles.uiuc.edu/dig/RefactoringInfo/WRT09/]

ACM SIGSOFT 2006 / FSE 14[http://www.cs.uoregon.edu/fse-14/]

29th Int. Conference on Software Engineering® 20 - 26 May 2007[http://web4.cs.ucl.ac.uk/icse07/]

21st IEEE/ACM International Conference on Automated Software Engineering[http://ase.cs.uni-essen.de/ase/past/ase2006/]

=== '''Web''' ===

Refactoring Info[https://netfiles.uiuc.edu/dig/RefactoringInfo/index.html]

www.refactoring.com [http://www.refactoring.com/]

Refactoring at AllExperts [http://en.allexperts.com/e/r/re/refactoring.html]

CSC/ECE 517 Fall 2009/wiki1a 9 DS

2009-09-08T02:11:16Z

Screenit:

'''REFACTORING TOOLS'''

----

== Definition ==

Refactoring[http://en.wikipedia.org/wiki/Code_refactoring] is defined as the technique by which the existing body of the code is restructured by changing the inner structure and preserving its external behavior. The tools which are used to achieve this purpose are commonly known as Refactoring Tools.

Refactoring tools are provided as Integrated Development Environment (IDE) features currently and are available for all popular programming languages. For instance, the common IDEs that provide the refactoring tools are IBM’s Eclipse, Sun’s Netbeans and IntelliJ’s IDEA. For further information, an academic thesis “Refactoring Tools and Complementary Techniques” focuses on the survey made on the comparison of refactoring tools usage in IDEs.

== Overview ==
This deals with the academic underpinnings of refactoring starting from its evolution and the initiatives taken to improve the current generation of refactoring tools. It also throws lights up on various books, academic thesis, conferences and workshops on the topic of refactoring.

== Academic Underpinnings ==

=== '''Motivation''' ===

The first official thesis on the area of refactoring leads back to 1992 when Bill Opdyke finished his thesis on the topic "Refactoring Object-Oriented Frameworks"[http://portal.acm.org/citation.cfm?id=169783&dl=GUIDE&coll=GUIDE&CFID=50708246&CFTOKEN=47231553]. Bill Opdyke was working in Bell Laboratories developing electronic switching systems.
When he started to pursue his doctoral studies he wanted it to be related to practical business applications. That is when he narrowed down on this topic which led to the official shaping of the cloud refactoring.

The Basic motivation behind the emergence of refactoring was the software re-usability and cutting down cost involved in restructuring software for various purposes. Thus refactoring leads to software reuse in future.

Though it might appear that refactoring began in research labs it actually emerged on an ad-hoc basis when object-oriented programmers came across situations where they felt the need for change in object oriented software. Refactoring actually has its roots way back. Factoring was a key technique in Forth Language from its birth in 70’s. Absence of appropriate syntax made it not possible to extract the best use out of it. Ralph Johnson was the first person to use the name refactoring in print. Along with Bill Opdyke he published a paper on refactoring in 1990.

=== '''Etymology''' ===

The first known use of the term “refactoring” appeared in “Refactoring: An Aid in Designing Application Frameworks and Evolving Object-Oriented Systems” by Ralph Johnson and Bill Opdyke in 1990. But Refactoring as a function and as a technique, was almost certainly used before then.

=== '''More Works''' ===

Lot of work has been done on this area which includes the thesis work “Practical Analysis for refactoring” [http://portal.acm.org/citation.cfm?id=871251] by Donald Bradley Roberts. It focuses on several ways to make a refactoring tool that is both fast and reliable enough to be useful. In another thesis work “Refactoring as Formal Refinements” [http://dsc.upe.br/~mlc/PhDThesis/RefactoringsAsFormalRefinements.pdf] by Márcio Cornélio throws light on algebraic technique that presents refactoring as behavior preserving transformation. For list of other thesis works and papers refer to the References section.

=== '''Books on Refactoring''' ===

Various books are available on the topic of refactoring these days. The initial list of books includes “Refactoring: Improving the Design of Existing Code“ [http://www.amazon.com/exec/obidos/ASIN/0201485672] by Martin Flower and Refactoring to Patterns [http://www.industriallogic.com/xp/refactoring/] by Joshua Kerievsky and many more books on this topic. For listing of books on refactoring refer to the external links.

== Initiatives taken to improve current generation of refactoring tools ==

=== '''Web Portal''' ===

Various initiatives like conferences, workshops are conducted by Organizations like Institute of Electrical and Electronics Engineers (IEEE), Associate for Computing Machinery (ACM) to improve the current generation of refactoring tools. The first initiative taken to improve the current generation of refactoring tools was the creation of the refactoring research web portal ([http://refactoring.info]).
This research web portal includes a collection of links and articles that provide the researchers and industrial engineers an up-to-date knowledge on refactoring.

=== '''Workshops and Conferences''' ===

The second initiative taken was, organization of workshops which serve as a forum to bring researchers and tool vendors together for collaborative efforts in developing the refactoring tools. This initiative has been taken with the motive to develop the tool support for refactoring efficiently by combining the state-of-the-art research with the challenges from real-time applications. The benefits of such workshops by collaborating the researchers and tool vendors are, to develop the tools in a short period of time and to eliminate the redundant works by other researchers and tool vendors. The workshops on refactoring tools are being conducted annually at various places

The first workshop on refactoring tools was conducted on July 31st 2007 in conjunction with European Conference on Object-Oriented Programming (ECOOP) [https://netfiles.uiuc.edu/dig/RefactoringWorkshop/] at Berlin. Various papers like automated refactoring for improved cohesion, reuse based refactoring tools, Engineering reusability for software refactoring tools and others were presented and discussed. The proceedings of the first workshop can be found as a TU Berlin Technical Report, ISSN 1436-9915.

The second workshop on refactoring tools was conducted on October 19th 2008 in conjunction with Object-Oriented Programming Systems, Languages and Applications (OOPSLA) [https://netfiles.uiuc.edu/dig/RefactoringInfo/WRT08/] at Nashville, Tennessee. Various papers that were accepted and discussed were Cross Language Refactoring for Eclipse plug-ins, Tool support for refactoring functional programs, Towards a Refactoring guideline using code clone classification and others. More accepted papers at the second workshop can be found at [https://agora.cs.illinois.edu/display/wrt08/Accepted+Papers]. The interest in research in refactoring tools has increased to a greater extent that more papers were submitted and more researchers and tool vendors like JetBrains, Microsoft participated at the workshop.

The third workshop on refactoring tools is going to be held on October 25-29, 2009 in conjunction with Object-Oriented Programming Systems, Languages and Applications (OOPSLA) [https://netfiles.uiuc.edu/dig/RefactoringInfo/WRT09/] at Orlando, Florida. The papers have been invited for the topics which include language-independent transformation frameworks, language-independent analysis frameworks and analytical representations.

=== '''Other Initiatives''' ===

Apart from workshops held specifically for refactoring tools, other conferences have been organized by Automated Software Engineering (ASE), International Conference on Software Engineering (ICSE), Foundations of Software Engineering (FSE) wherein papers on refactoring have been presented and awarded the best paper award.

In addition to the workshops and conferences, the weekly contest on refactoring “Refactor It! The Weekly Book Giveaway” has been started by Billy McCafferty to increase the awareness and interest among the software developers, students and other programming communities. Various groups like Software Architecture Group (SAG) at University of Illinois at Urbana-Champaign, Program Analysis and Transformation (PAT) group at IBM TJ Watson Research Center have been organized at Universities and Organizations to conduct research in refactoring tools and to improve the current generation of refactoring tools. More details about various groups and people can be found at [https://netfiles.uiuc.edu/dig/RefactoringInfo/people.html]

== External Links ==

Refactor It contest [http://devlicio.us/blogs/billy_mccafferty/archive/2006/11/13/refactor-it-the-weekly-book-giveaway.aspx]

Code It Software [http://submain.com/products/codeit.once.aspx]

=== '''Books''' ===

Refactoring Workbook - William.C.Wake [http://www.amazon.com/exec/obidos/tg/detail/-/0321109295]

Refactoring to Patterns - [http://industriallogic.com/xp/refactoring/]

Refactoring Databases : Evolutionary Database Design - [http://www.amazon.com/exec/obidos/ASIN/0321293533]

Professional Refactoring in Visual Basic - [http://www.amazon.com/gp/product/0470179791]

CoreJ2EE Patterns - [http://www.amazon.com/Core-J2EE-Patterns-Practices-Strategies/dp/0131422464]

== References ==

=== '''Thesis Works''' ===

William F. Opdyke, Refactoring object-oriented frameworks, University of Illinois at Urbana-Champaign, Champaign, IL, 1992 [http://portal.acm.org/citation.cfm?id=169783&dl=GUIDE&coll=GUIDE&CFID=50708246&CFTOKEN=47231553]

Refactoring as Formal Refinements- Marico Lopes Cornelio [http://dsc.upe.br/~mlc/PhDThesis/RefactoringsAsFormalRefinements.pdf]

Practical Analysis for Refactoring – Donald B Roberts, University of Illinois at Urbana-Champaign Champaign, IL, USA[http://portal.acm.org/citation.cfm?id=871251]

Refactoring Tools and Complementary Techniques - Martin Drozdz, Derrick G Kourie, Bruce W Watson, Andrew Boake Espresso Research Group, Department of Computer Science, University of Pretoria, Pretoria, South Africa 0001 [http://www2.computer.org/portal/web/csdl/doi/10.1109/AICCSA.2006.205164]

=== '''Other Papers/Conferences''' ===

William F. Opdyke and Ralph E. Johnson. Refactoring: An aid in designing application frameworks and evolving object-oriented systems. In Proceedings of Symposium on Object- Oriented Programming Emphasizing Practical Applications (SOOPPA), September 1990.

Refactoring, Reuse & Reality, Bill Opdyke, Lucent Technologies/ Bell Labs, Copyright 1999, Lucent Technologies[http://chip.cs.uiuc.edu/users/opdyke/wfo.990201.refac.html]

First workshop on refactoring in conjunction with ecoop Berlin 07 [https://netfiles.uiuc.edu/dig/RefactoringWorkshop/]

Second ACM Workshop on Refactoring Tools (WRT'08)[https://netfiles.uiuc.edu/dig/RefactoringInfo/WRT08/]

Accepted papers for WRT’08 [https://agora.cs.illinois.edu/display/wrt08/Accepted+Papers]

Third ACM Workshop on Refactoring Tools (WRT'09)[https://netfiles.uiuc.edu/dig/RefactoringInfo/WRT09/]

ACM SIGSOFT 2006 / FSE 14[http://www.cs.uoregon.edu/fse-14/]

29th Int. Conference on Software Engineering® 20 - 26 May 2007[http://web4.cs.ucl.ac.uk/icse07/]

21st IEEE/ACM International Conference on Automated Software Engineering[http://ase.cs.uni-essen.de/ase/past/ase2006/]

=== '''Web''' ===

Refactoring Info[https://netfiles.uiuc.edu/dig/RefactoringInfo/index.html]

www.refactoring.com [http://www.refactoring.com/]

Refactoring at AllExperts [http://en.allexperts.com/e/r/re/refactoring.html]

CSC/ECE 517 Fall 2009/wiki1a 9 DS

2009-09-08T01:53:06Z

Screenit: /* '''Etymology''' */

'''REFACTORING TOOLS'''

----

== Definition ==

Refactoring[http://en.wikipedia.org/wiki/Code_refactoring] is defined as the technique by which the existing body of the code is restructured by changing the inner structure and preserving its external behavior. The tools which are used to achieve this purpose are commonly known as Refactoring Tools.

Refactoring tools are provided as Integrated Development Environment (IDE) features currently and are available for all popular programming languages. For instance, the common IDEs that provide the refactoring tools are IBM’s Eclipse, Sun’s Netbeans and IntelliJ’s IDEA. For further information, an academic thesis “Refactoring Tools and Complementary Techniques” focuses on the survey made on the comparison of refactoring tools usage in IDEs.

== Overview ==
This deals with the academic underpinnings of refactoring starting from its evolution and the initiatives taken to improve the current generation of refactoring tools. It also throws lights up on various books, academic thesis, conferences and workshops on the topic of refactoring.

== Academic Underpinnings ==

=== '''Motivation''' ===

The first official thesis on the area of refactoring leads back to 1992 when Bill Opdyke finished his thesis on the topic "Refactoring Object-Oriented Frameworks"[http://portal.acm.org/citation.cfm?id=169783&dl=GUIDE&coll=GUIDE&CFID=50708246&CFTOKEN=47231553]. Bill Opdyke was working in Bell Laboratories developing electronic switching systems.
When he started to pursue his doctoral studies he wanted it to be related to practical business applications. That is when he narrowed down on this topic which led to the official shaping of the cloud refactoring.

The Basic motivation behind the emergence of refactoring was the software re-usability and cutting down cost involved in restructuring software for various purposes. Thus refactoring leads to software reuse in future.

Though it might appear that refactoring began in research labs it actually emerged on an ad-hoc basis when object-oriented programmers came across situations where they felt the need for change in object oriented software. Refactoring actually has its roots way back. Factoring was a key technique in Forth Language from its birth in 70’s. Absence of appropriate syntax made it not possible to extract the best use out of it. Ralph Johnson was the first person to use the name refactoring in print. Along with Bill Opdyke he published a paper on refactoring in 1990.

=== '''Etymology''' ===

The first known use of the term “refactoring” appeared in “Refactoring: An Aid in Designing Application Frameworks and Evolving Object-Oriented Systems” by Ralph Johnson and Bill Opdyke in 1990. But Refactoring as a function and as a technique, was almost certainly used before then.

=== '''More Works''' ===

Lot of work has been done on this area which includes the thesis work “Practical Analysis for refactoring” by Donald Bradley Roberts. It focuses on several ways to make a refactoring tool that is both fast enough and reliable enough to be useful. In another thesis work “Refactoring as Formal Refinements” by Márcio Cornélio throws light on algebraic technique that presents refactoring as behavior preserving transformation. For list of other thesis works and papers refer to the external links.

=== '''Books on Refactoring''' ===

Various books are available on the topic of refactoring these days. The initial list of books includes “Refactoring: Improving the Design of Existing Code“ by Martin Flower and Refactoring to Patterns, by Joshua Kerievsky and many more books on this topic. For listing of books refer to the external links on books on refactoring.

== Initiatives taken to improve current generation of refactoring tools ==

=== '''Web Portal''' ===

Various initiatives like conferences, workshops are conducted by Organizations like Institute of Electrical and Electronics Engineers (IEEE), Associate for Computing Machinery (ACM) to improve the current generation of refactoring tools. The first initiative taken to improve the current generation of refactoring tools is creating the refactoring research web portal ([http://refactoring.info]).
This research web portal includes a collection links and articles that provide the researchers and industrial engineers an up-to-date knowledge on refactoring.

=== '''Workshops and Conferences''' ===

The second initiative taken is, organizing workshops which serve as a forum to bring researchers and tool vendors together for collaborative efforts in developing the refactoring tools. This initiative has been taken with the motive to develop the tool support for refactoring efficiently by combining the state-of-the-art research with the challenges from real-time applications. The benefits of such workshops by collaborating the researchers and tool vendors are, to develop the tools in a short period of time and eliminating the redundant works by other researchers and tool vendors. The workshops on refactoring tools are being conducted annually at various places

The first workshop on refactoring tools was conducted on July 31st 2007 in conjunction with European Conference on Object-Oriented Programming (ECOOP) at Berlin. Various papers like automated refactoring for improved cohesion, reuse based refactoring tools, Engineering reusability for software refactoring tools and others were presented and discussed. The proceedings of the first workshop can be found as a TU Berlin Technical Report, ISSN 1436-9915.

The second workshop on refactoring tools was conducted on October 19th 2008 in conjunction with Object-Oriented Programming Systems, Languages and Applications (OOPSLA) at Nashville, Tennessee. Various papers that were accepted and discussed were Cross Language Refactoring for Eclipse plug-ins, Tool support for refactoring functional programs, Towards a Refactoring guideline using code clone classification and others. More accepted papers at the second workshop can be found at [https://agora.cs.illinois.edu/display/wrt08/Accepted+Papers]. The interest in research in refactoring tools has increased to a greater extent that more papers were submitted and more researchers and tool vendors like JetBrains, Microsoft participated at the workshop.

The third workshop on refactoring tools is going to be held on October 25-29, 2009 in conjunction with Object-Oriented Programming Systems, Languages and Applications (OOPSLA) at Orlando, Florida. The papers have been invited for the topics which include language-independent transformation frameworks, language-independent analysis frameworks and analytical representations.

=== '''Other Initiatives''' ===

Apart from workshops held specifically for refactoring tools, other conferences have been organized by Automated Software Engineering (ASE), International Conference on Software Engineering (ICSE), Foundations of Software Engineering (FSE) wherein papers on refactoring have been presented and awarded the best paper award.

In addition to the workshops and conferences, the weekly contest on refactoring “Refactor It! The Weekly Book Giveaway” has been started by Billy McCafferty to increase the awareness and interest among the software developers, students and other programming communities. Various groups like Software Architecture Group (SAG) at University of Illinois at Urbana-Champaign, Program Analysis and Transformation (PAT) group at IBM TJ Watson Research Center have been organized at Universities and Organizations to conduct research in refactoring tools and to improve the current generation of refactoring tools. More details about various groups and people can be found at [https://netfiles.uiuc.edu/dig/RefactoringInfo/people.html]

== External Links ==

Refactor It contest [http://devlicio.us/blogs/billy_mccafferty/archive/2006/11/13/refactor-it-the-weekly-book-giveaway.aspx]

Code It Software [http://submain.com/products/codeit.once.aspx]

=== '''Books''' ===

Refactoring Workbook - William.C.Wake [http://www.amazon.com/exec/obidos/tg/detail/-/0321109295]

Refactoring to Patterns - [http://industriallogic.com/xp/refactoring/]

Refactoring Databases : Evolutionary Database Design - [http://www.amazon.com/exec/obidos/ASIN/0321293533]

Professional Refactoring in Visual Basic - [http://www.amazon.com/gp/product/0470179791]

CoreJ2EE Patterns - [http://www.amazon.com/Core-J2EE-Patterns-Practices-Strategies/dp/0131422464]

== References ==

=== '''Thesis Works''' ===

William F. Opdyke, Refactoring object-oriented frameworks, University of Illinois at Urbana-Champaign, Champaign, IL, 1992 [http://portal.acm.org/citation.cfm?id=169783&dl=GUIDE&coll=GUIDE&CFID=50708246&CFTOKEN=47231553]

Refactoring as Formal Refinements- Marico Lopes Cornelio [http://dsc.upe.br/~mlc/PhDThesis/RefactoringsAsFormalRefinements.pdf]

Practical Analysis for Refactoring – Donald B Roberts, University of Illinois at Urbana-Champaign Champaign, IL, USA[http://portal.acm.org/citation.cfm?id=871251]

Refactoring Tools and Complementary Techniques - Martin Drozdz, Derrick G Kourie, Bruce W Watson, Andrew Boake Espresso Research Group, Department of Computer Science, University of Pretoria, Pretoria, South Africa 0001 [http://www2.computer.org/portal/web/csdl/doi/10.1109/AICCSA.2006.205164]

=== '''Other Papers/Conferences''' ===

William F. Opdyke and Ralph E. Johnson. Refactoring: An aid in designing application frameworks and evolving object-oriented systems. In Proceedings of Symposium on Object- Oriented Programming Emphasizing Practical Applications (SOOPPA), September 1990.

Refactoring, Reuse & Reality, Bill Opdyke, Lucent Technologies/ Bell Labs, Copyright 1999, Lucent Technologies[http://chip.cs.uiuc.edu/users/opdyke/wfo.990201.refac.html]

First workshop on refactoring in conjunction with ecoop Berlin 07 [https://netfiles.uiuc.edu/dig/RefactoringWorkshop/]

Second ACM Workshop on Refactoring Tools (WRT'08)[https://netfiles.uiuc.edu/dig/RefactoringInfo/WRT08/]

Accepted papers for WRT’08 [https://agora.cs.illinois.edu/display/wrt08/Accepted+Papers]

Third ACM Workshop on Refactoring Tools (WRT'09)[https://netfiles.uiuc.edu/dig/RefactoringInfo/WRT09/]

ACM SIGSOFT 2006 / FSE 14[http://www.cs.uoregon.edu/fse-14/]

29th Int. Conference on Software Engineering® 20 - 26 May 2007[http://web4.cs.ucl.ac.uk/icse07/]

21st IEEE/ACM International Conference on Automated Software Engineering[http://ase.cs.uni-essen.de/ase/past/ase2006/]

=== '''Web''' ===

Refactoring Info[https://netfiles.uiuc.edu/dig/RefactoringInfo/index.html]

www.refactoring.com [http://www.refactoring.com/]

Refactoring at AllExperts [http://en.allexperts.com/e/r/re/refactoring.html]

CSC/ECE 517 Fall 2009/wiki1a 9 DS

2009-09-08T01:51:58Z

Screenit:

'''REFACTORING TOOLS'''

----

== Definition ==

Refactoring[http://en.wikipedia.org/wiki/Code_refactoring] is defined as the technique by which the existing body of the code is restructured by changing the inner structure and preserving its external behavior. The tools which are used to achieve this purpose are commonly known as Refactoring Tools.

Refactoring tools are provided as Integrated Development Environment (IDE) features currently and are available for all popular programming languages. For instance, the common IDEs that provide the refactoring tools are IBM’s Eclipse, Sun’s Netbeans and IntelliJ’s IDEA. For further information, an academic thesis “Refactoring Tools and Complementary Techniques” focuses on the survey made on the comparison of refactoring tools usage in IDEs.

== Overview ==
This deals with the academic underpinnings of refactoring starting from its evolution and the initiatives taken to improve the current generation of refactoring tools. It also throws lights up on various books, academic thesis, conferences and workshops on the topic of refactoring.

== Academic Underpinnings ==

=== '''Motivation''' ===

The first official thesis on the area of refactoring leads back to 1992 when Bill Opdyke finished his thesis on the topic "Refactoring Object-Oriented Frameworks"[http://portal.acm.org/citation.cfm?id=169783&dl=GUIDE&coll=GUIDE&CFID=50708246&CFTOKEN=47231553]. Bill Opdyke was working in Bell Laboratories developing electronic switching systems.
When he started to pursue his doctoral studies he wanted it to be related to practical business applications. That is when he narrowed down on this topic which led to the official shaping of the cloud refactoring.

The Basic motivation behind the emergence of refactoring was the software re-usability and cutting down cost involved in restructuring software for various purposes. Thus refactoring leads to software reuse in future.

Though it might appear that refactoring began in research labs it actually emerged on an ad-hoc basis when object-oriented programmers came across situations where they felt the need for change in object oriented software. Refactoring actually has its roots way back. Factoring was a key technique in Forth Language from its birth in 70’s. Absence of appropriate syntax made it not possible to extract the best use out of it. Ralph Johnson was the first person to use the name refactoring in print. Along with Bill Opdyke he published a paper on refactoring in 1990.

=== '''Etymology''' ===

The first known use of the term “refactoring” appeared in “Refactoring: An Aid in Designing Application Frameworks and Evolving Object-Oriented Systems” by Ralph Johnson and Bill Opdyke in 1990. But Refactoring as a function and as technique was almost certainly used before then.

=== '''More Works''' ===

Lot of work has been done on this area which includes the thesis work “Practical Analysis for refactoring” by Donald Bradley Roberts. It focuses on several ways to make a refactoring tool that is both fast enough and reliable enough to be useful. In another thesis work “Refactoring as Formal Refinements” by Márcio Cornélio throws light on algebraic technique that presents refactoring as behavior preserving transformation. For list of other thesis works and papers refer to the external links.

=== '''Books on Refactoring''' ===

Various books are available on the topic of refactoring these days. The initial list of books includes “Refactoring: Improving the Design of Existing Code“ by Martin Flower and Refactoring to Patterns, by Joshua Kerievsky and many more books on this topic. For listing of books refer to the external links on books on refactoring.

== Initiatives taken to improve current generation of refactoring tools ==

=== '''Web Portal''' ===

Various initiatives like conferences, workshops are conducted by Organizations like Institute of Electrical and Electronics Engineers (IEEE), Associate for Computing Machinery (ACM) to improve the current generation of refactoring tools. The first initiative taken to improve the current generation of refactoring tools is creating the refactoring research web portal ([http://refactoring.info]).
This research web portal includes a collection links and articles that provide the researchers and industrial engineers an up-to-date knowledge on refactoring.

=== '''Workshops and Conferences''' ===

The second initiative taken is, organizing workshops which serve as a forum to bring researchers and tool vendors together for collaborative efforts in developing the refactoring tools. This initiative has been taken with the motive to develop the tool support for refactoring efficiently by combining the state-of-the-art research with the challenges from real-time applications. The benefits of such workshops by collaborating the researchers and tool vendors are, to develop the tools in a short period of time and eliminating the redundant works by other researchers and tool vendors. The workshops on refactoring tools are being conducted annually at various places

The first workshop on refactoring tools was conducted on July 31st 2007 in conjunction with European Conference on Object-Oriented Programming (ECOOP) at Berlin. Various papers like automated refactoring for improved cohesion, reuse based refactoring tools, Engineering reusability for software refactoring tools and others were presented and discussed. The proceedings of the first workshop can be found as a TU Berlin Technical Report, ISSN 1436-9915.

The second workshop on refactoring tools was conducted on October 19th 2008 in conjunction with Object-Oriented Programming Systems, Languages and Applications (OOPSLA) at Nashville, Tennessee. Various papers that were accepted and discussed were Cross Language Refactoring for Eclipse plug-ins, Tool support for refactoring functional programs, Towards a Refactoring guideline using code clone classification and others. More accepted papers at the second workshop can be found at [https://agora.cs.illinois.edu/display/wrt08/Accepted+Papers]. The interest in research in refactoring tools has increased to a greater extent that more papers were submitted and more researchers and tool vendors like JetBrains, Microsoft participated at the workshop.

The third workshop on refactoring tools is going to be held on October 25-29, 2009 in conjunction with Object-Oriented Programming Systems, Languages and Applications (OOPSLA) at Orlando, Florida. The papers have been invited for the topics which include language-independent transformation frameworks, language-independent analysis frameworks and analytical representations.

=== '''Other Initiatives''' ===

Apart from workshops held specifically for refactoring tools, other conferences have been organized by Automated Software Engineering (ASE), International Conference on Software Engineering (ICSE), Foundations of Software Engineering (FSE) wherein papers on refactoring have been presented and awarded the best paper award.

In addition to the workshops and conferences, the weekly contest on refactoring “Refactor It! The Weekly Book Giveaway” has been started by Billy McCafferty to increase the awareness and interest among the software developers, students and other programming communities. Various groups like Software Architecture Group (SAG) at University of Illinois at Urbana-Champaign, Program Analysis and Transformation (PAT) group at IBM TJ Watson Research Center have been organized at Universities and Organizations to conduct research in refactoring tools and to improve the current generation of refactoring tools. More details about various groups and people can be found at [https://netfiles.uiuc.edu/dig/RefactoringInfo/people.html]

== External Links ==

Refactor It contest [http://devlicio.us/blogs/billy_mccafferty/archive/2006/11/13/refactor-it-the-weekly-book-giveaway.aspx]

Code It Software [http://submain.com/products/codeit.once.aspx]

=== '''Books''' ===

Refactoring Workbook - William.C.Wake [http://www.amazon.com/exec/obidos/tg/detail/-/0321109295]

Refactoring to Patterns - [http://industriallogic.com/xp/refactoring/]

Refactoring Databases : Evolutionary Database Design - [http://www.amazon.com/exec/obidos/ASIN/0321293533]

Professional Refactoring in Visual Basic - [http://www.amazon.com/gp/product/0470179791]

CoreJ2EE Patterns - [http://www.amazon.com/Core-J2EE-Patterns-Practices-Strategies/dp/0131422464]

== References ==

=== '''Thesis Works''' ===

William F. Opdyke, Refactoring object-oriented frameworks, University of Illinois at Urbana-Champaign, Champaign, IL, 1992 [http://portal.acm.org/citation.cfm?id=169783&dl=GUIDE&coll=GUIDE&CFID=50708246&CFTOKEN=47231553]

Refactoring as Formal Refinements- Marico Lopes Cornelio [http://dsc.upe.br/~mlc/PhDThesis/RefactoringsAsFormalRefinements.pdf]

Practical Analysis for Refactoring – Donald B Roberts, University of Illinois at Urbana-Champaign Champaign, IL, USA[http://portal.acm.org/citation.cfm?id=871251]

Refactoring Tools and Complementary Techniques - Martin Drozdz, Derrick G Kourie, Bruce W Watson, Andrew Boake Espresso Research Group, Department of Computer Science, University of Pretoria, Pretoria, South Africa 0001 [http://www2.computer.org/portal/web/csdl/doi/10.1109/AICCSA.2006.205164]

=== '''Other Papers/Conferences''' ===

William F. Opdyke and Ralph E. Johnson. Refactoring: An aid in designing application frameworks and evolving object-oriented systems. In Proceedings of Symposium on Object- Oriented Programming Emphasizing Practical Applications (SOOPPA), September 1990.

Refactoring, Reuse & Reality, Bill Opdyke, Lucent Technologies/ Bell Labs, Copyright 1999, Lucent Technologies[http://chip.cs.uiuc.edu/users/opdyke/wfo.990201.refac.html]

First workshop on refactoring in conjunction with ecoop Berlin 07 [https://netfiles.uiuc.edu/dig/RefactoringWorkshop/]

Second ACM Workshop on Refactoring Tools (WRT'08)[https://netfiles.uiuc.edu/dig/RefactoringInfo/WRT08/]

Accepted papers for WRT’08 [https://agora.cs.illinois.edu/display/wrt08/Accepted+Papers]

Third ACM Workshop on Refactoring Tools (WRT'09)[https://netfiles.uiuc.edu/dig/RefactoringInfo/WRT09/]

ACM SIGSOFT 2006 / FSE 14[http://www.cs.uoregon.edu/fse-14/]

29th Int. Conference on Software Engineering® 20 - 26 May 2007[http://web4.cs.ucl.ac.uk/icse07/]

21st IEEE/ACM International Conference on Automated Software Engineering[http://ase.cs.uni-essen.de/ase/past/ase2006/]

=== '''Web''' ===

Refactoring Info[https://netfiles.uiuc.edu/dig/RefactoringInfo/index.html]

www.refactoring.com [http://www.refactoring.com/]

Refactoring at AllExperts [http://en.allexperts.com/e/r/re/refactoring.html]

CSC/ECE 517 Fall 2009/wiki1a 9 DS

2009-09-08T01:41:25Z

Screenit: /* Overview */

'''REFACTORING TOOLS'''

----

== Definition ==

Refactoring[http://en.wikipedia.org/wiki/Code_refactoring] is defined as the technique by which the existing body of the code is restructured by changing the inner structure and preserving its external behavior. The tools which are used to achieve this purpose are commonly known as Refactoring Tools.

Refactoring tools are provided as Integrated Development Environment (IDE) features currently and are available for all popular programming languages. For instance, the common IDEs that provide the refactoring tools are IBM’s Eclipse, Sun’s Netbeans and IntelliJ’s IDEA. For further information, an academic thesis “Refactoring Tools and Complementary Techniques” focuses on the survey made on the comparison of refactoring tools usage in IDEs.

== Overview ==
This deals with the academic underpinnings of refactoring starting from its evolution and the initiatives taken to improve the current generation of refactoring tools. It also throws lights up on various books, academic thesis, conferences and workshops on the topic of refactoring.

== Academic Underpinnings ==

=== '''Motivation''' ===

The first official thesis on the area of refactoring leads back to 1992 when Bill Opdyke finished his thesis on the topic "Refactoring Object-Oriented Frameworks". Bill Opdyke was working in Bill Laboratories developing electronic switching systems.
When he started to pursue his doctoral studies he wanted it to be related to practical business application. That is when he narrowed down on this topic and lead to the official shaping of the cloud refactoring.

The Basic motivation behind the emergence of refactoring was the software re usability, cutting down cost involved in restructuring software later for various use. Thus refactoring leads to software reuse in future.

Though it might appear that refactoring began in research labs it actually emerged on ad-hoc basis when object-oriented programmers came across situations where they felt the need for change in object oriented software. Refactoring actually has its roots way back. Factoring was a key technique in Forth Language from its birth in 70’s. Absence of appropriate syntax made it not possible to extract the best use out of it. Ralph jhonson was the first person to use the name refactoring in print. Along with Bill Opdyke he published a paper on refactoring in 1990.

=== '''Etymology''' ===

The first known use of the term “refactoring” appeared in “Refactoring: An Aid in Designing Application Frameworks and Evolving Object-Oriented Systems” by Ralph Johnson and Bill Opdyke in 1990. But Refactoring as a function and as technique was almost certainly used before then.

=== '''More Works''' ===

Lot of work has been done on this area which includes the thesis work “Practical Analysis for refactoring” by Donald Bradley Roberts. It focuses on several ways to make a refactoring tool that is both fast enough and reliable enough to be useful. In another thesis work “Refactoring as Formal Refinements” by Márcio Cornélio throws light on algebraic technique that presents refactoring as behavior preserving transformation. For list of other thesis works and papers refer to the external links.

=== '''Books on Refactoring''' ===

Various books are available on the topic of refactoring these days. The initial list of books includes “Refactoring: Improving the Design of Existing Code“ by Martin Flower and Refactoring to Patterns, by Joshua Kerievsky and many more books on this topic. For listing of books refer to the external links on books on refactoring.

== Initiatives taken to improve current generation of refactoring tools ==

=== '''Web Portal''' ===

Various initiatives like conferences, workshops are conducted by Organizations like Institute of Electrical and Electronics Engineers (IEEE), Associate for Computing Machinery (ACM) to improve the current generation of refactoring tools. The first initiative taken to improve the current generation of refactoring tools is creating the refactoring research web portal ([http://refactoring.info]).
This research web portal includes a collection links and articles that provide the researchers and industrial engineers an up-to-date knowledge on refactoring.

=== '''Workshops and Conferences''' ===

The second initiative taken is, organizing workshops which serve as a forum to bring researchers and tool vendors together for collaborative efforts in developing the refactoring tools. This initiative has been taken with the motive to develop the tool support for refactoring efficiently by combining the state-of-the-art research with the challenges from real-time applications. The benefits of such workshops by collaborating the researchers and tool vendors are, to develop the tools in a short period of time and eliminating the redundant works by other researchers and tool vendors. The workshops on refactoring tools are being conducted annually at various places

The first workshop on refactoring tools was conducted on July 31st 2007 in conjunction with European Conference on Object-Oriented Programming (ECOOP) at Berlin. Various papers like automated refactoring for improved cohesion, reuse based refactoring tools, Engineering reusability for software refactoring tools and others were presented and discussed. The proceedings of the first workshop can be found as a TU Berlin Technical Report, ISSN 1436-9915.

The second workshop on refactoring tools was conducted on October 19th 2008 in conjunction with Object-Oriented Programming Systems, Languages and Applications (OOPSLA) at Nashville, Tennessee. Various papers that were accepted and discussed were Cross Language Refactoring for Eclipse plug-ins, Tool support for refactoring functional programs, Towards a Refactoring guideline using code clone classification and others. More accepted papers at the second workshop can be found at [https://agora.cs.illinois.edu/display/wrt08/Accepted+Papers]. The interest in research in refactoring tools has increased to a greater extent that more papers were submitted and more researchers and tool vendors like JetBrains, Microsoft participated at the workshop.

The third workshop on refactoring tools is going to be held on October 25-29, 2009 in conjunction with Object-Oriented Programming Systems, Languages and Applications (OOPSLA) at Orlando, Florida. The papers have been invited for the topics which include language-independent transformation frameworks, language-independent analysis frameworks and analytical representations.

=== '''Other Initiatives''' ===

Apart from workshops held specifically for refactoring tools, other conferences have been organized by Automated Software Engineering (ASE), International Conference on Software Engineering (ICSE), Foundations of Software Engineering (FSE) wherein papers on refactoring have been presented and awarded the best paper award.

In addition to the workshops and conferences, the weekly contest on refactoring “Refactor It! The Weekly Book Giveaway” has been started by Billy McCafferty to increase the awareness and interest among the software developers, students and other programming communities. Various groups like Software Architecture Group (SAG) at University of Illinois at Urbana-Champaign, Program Analysis and Transformation (PAT) group at IBM TJ Watson Research Center have been organized at Universities and Organizations to conduct research in refactoring tools and to improve the current generation of refactoring tools. More details about various groups and people can be found at [https://netfiles.uiuc.edu/dig/RefactoringInfo/people.html]

== External Links ==

Refactor It contest [http://devlicio.us/blogs/billy_mccafferty/archive/2006/11/13/refactor-it-the-weekly-book-giveaway.aspx]

Code It Software [http://submain.com/products/codeit.once.aspx]

=== '''Books''' ===

Refactoring Workbook - William.C.Wake [http://www.amazon.com/exec/obidos/tg/detail/-/0321109295]

Refactoring to Patterns - [http://industriallogic.com/xp/refactoring/]

Refactoring Databases : Evolutionary Database Design - [http://www.amazon.com/exec/obidos/ASIN/0321293533]

Professional Refactoring in Visual Basic - [http://www.amazon.com/gp/product/0470179791]

CoreJ2EE Patterns - [http://www.amazon.com/Core-J2EE-Patterns-Practices-Strategies/dp/0131422464]

== References ==

=== '''Thesis Works''' ===

William F. Opdyke, Refactoring object-oriented frameworks, University of Illinois at Urbana-Champaign, Champaign, IL, 1992 [http://portal.acm.org/citation.cfm?id=169783&dl=GUIDE&coll=GUIDE&CFID=50708246&CFTOKEN=47231553]

Refactoring as Formal Refinements- Marico Lopes Cornelio [http://dsc.upe.br/~mlc/PhDThesis/RefactoringsAsFormalRefinements.pdf]

Practical Analysis for Refactoring – Donald B Roberts, University of Illinois at Urbana-Champaign Champaign, IL, USA[http://portal.acm.org/citation.cfm?id=871251]

Refactoring Tools and Complementary Techniques - Martin Drozdz, Derrick G Kourie, Bruce W Watson, Andrew Boake Espresso Research Group, Department of Computer Science, University of Pretoria, Pretoria, South Africa 0001 [http://www2.computer.org/portal/web/csdl/doi/10.1109/AICCSA.2006.205164]

=== '''Other Papers/Conferences''' ===

William F. Opdyke and Ralph E. Johnson. Refactoring: An aid in designing application frameworks and evolving object-oriented systems. In Proceedings of Symposium on Object- Oriented Programming Emphasizing Practical Applications (SOOPPA), September 1990.

Refactoring, Reuse & Reality, Bill Opdyke, Lucent Technologies/ Bell Labs, Copyright 1999, Lucent Technologies[http://chip.cs.uiuc.edu/users/opdyke/wfo.990201.refac.html]

First workshop on refactoring in conjunction with ecoop Berlin 07 [https://netfiles.uiuc.edu/dig/RefactoringWorkshop/]

Second ACM Workshop on Refactoring Tools (WRT'08)[https://netfiles.uiuc.edu/dig/RefactoringInfo/WRT08/]

Accepted papers for WRT’08 [https://agora.cs.illinois.edu/display/wrt08/Accepted+Papers]

Third ACM Workshop on Refactoring Tools (WRT'09)[https://netfiles.uiuc.edu/dig/RefactoringInfo/WRT09/]

ACM SIGSOFT 2006 / FSE 14[http://www.cs.uoregon.edu/fse-14/]

29th Int. Conference on Software Engineering® 20 - 26 May 2007[http://web4.cs.ucl.ac.uk/icse07/]

21st IEEE/ACM International Conference on Automated Software Engineering[http://ase.cs.uni-essen.de/ase/past/ase2006/]

=== '''Web''' ===

Refactoring Info[https://netfiles.uiuc.edu/dig/RefactoringInfo/index.html]

www.refactoring.com [http://www.refactoring.com/]