Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2010/ch6 6j SO

2010-11-26T05:25:47Z

Solo2012: /* SOA Implementation using J2EE */

= Service-oriented architecture =

== Introduction ==

SOA (service-oriented architecture) has become a buzzword of late. The World Wide Web Consortium (W3C) refers to SOA as 'A set of components which can be invoked, and whose interface descriptions can be published and discovered'. Only a technical person can understand this definition. A simplified version of this definition would be -

''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. The combination of services - internal and external to an organization - makes up a service-oriented architecture.''

Although the concepts behind SOA have been around for over a decade now, SOA has gained extreme popularity of late due to web services. Before we dive into the details, let us step back and examine the context for the evolution of SOA. To do that, we have to simply look at the challenges faced by the developers over the past few decades and observe the solutions that have been proposed to solve their problems.

== The Problem ==

Early programmers soon realized that writing software was becoming way too complex. They realised the need of reusing some of the code they were rewriting. Researchers had a new mantra: go-to considered harmful. They introduced the concept of modular design. Modular design deals with the use of routines, sub routines and functions in order to organize and execute specific sets of instructions which helped programmers to reuse their code. This concept was again OK for smaller programs. But as the size and the complexity increased this started to create a maintenance nightmare. When a bug was discovered in a function somewhere, they had to track down all of the applications that used the function and modify the code to reflect the fix. Also, here we lay stress only on the steps of execution, but we are hardly bothered about the data for which all these has been done. This laid the groundwork for thinking new concepts, which would give absolute data security and OOPs evolved.

To solve these problems researchers proposed object-oriented software. Again, as software complexity grew, developers realized that developing and maintaining software was complex and they wanted a way to reuse and maintain functionality, not just code. Researchers offered yet another abstraction layer to handle this complexity -- component-based software. Component-based software is/was a good solution for reuse and maintenance, but it doesn't address all of the complexities developers are faced with today. Today, we face complex issues like distributed software, application integration, varying platforms, varying protocols, various devices, the Internet, etc. Today's software has to be equipped to answer the call for all of the above. In short, SOA (along with web services) provides a solution to all of the above. By adopting a SOA, you eliminate the headaches of protocol and platforms and your applications integrate seamlessly.

== Key Components of SOA ==

The first step in learning something new is to understand its vocabulary. In the context of SOA, we have the terms service, message, dynamic discovery, and web services. Each of these plays an essential role in SOA.

=== Service ===

A service in SOA is an exposed piece of functionality with three properties:

1. The interface contract to the service is platform-independent.

2. The service can be dynamically located and invoked.

3. The service is self-contained. That is, the service maintains its own state.

A platform-independent interface contract implies that a client from anywhere, on any OS, and in any language, can consume the service. Dynamic discovery hints that a discovery service (e.g., a directory service) is available. The directory service enables a look-up mechanism where consumers can go to find a service based on some criteria. For example, if some one was looking for a credit-card authorization service, he might query the directory service to find a list of service providers that could authorize a credit card for a fee. Based on the fee, he would select a service (see Figure below). The last property of a service is that the service be self-contained.

[[Image:SOA.gif|400x500px]]

=== Message ===

Service providers and consumers communicate via messages. Services expose an interface contract. This contract defines the behavior of the service and the messages they accept and return. Because the interface contract is platform- and language-independent, the technology used to define messages must also be agnostic to any specific platform/language. Therefore, messages are typically constructed using XML documents that conform to XML schema. XML provides all of the functionality, granularity, and scalability required by messages. That is, for consumers and providers to effectively communicate, they need a non-restrictive type of system to clearly define messages; XML provides this. Because consumers and providers communicate via messages, the structure and design of messages should not be taken lightly. Messages need to be implemented using a technology that supports the scalability requirements of services. Having to redesign messages will break the interface to providers, which can prove to be costly.

=== Dynamic Discovery ===

Dynamic discovery is an important piece of SOA. At a high level, SOA is composed of three core pieces: service providers, service consumers, and the directory service. The role of providers and consumers are apparent, but the role of the directory service needs some explanation. The directory service is an intermediary between providers and consumers. Providers register with the directory service and consumers query the directory service to find service providers. Most directory services typically organize services based on criteria and categorize them. Consumers can then use the directory services' search capabilities to find providers. Embedding a directory service within SOA accomplishes the following:

1. Scalability of services; you can add services incrementally.

2. Decouples consumers from providers.

3. Allows for hot updates of services.

4. Provides a look-up service for consumers.

5. Allows consumers to choose between providers at runtime rather than hard-coding a single provider.

=== Web Service ===

Although the concepts behind SOA were established long before web services came along, web services play a major role in a SOA. This is because web services are built on top of well-known and platform-independent protocols. These protocols include HTTP, XML, UDDI, WSDL, and SOAP. It is the combination of these protocols that make web services so attractive. Moreover, it is these protocols that fulfill the key requirements of a SOA. That is, a SOA requires that a service be dynamically discoverable and invokeable. This requirement is fulfilled by UDDI, WSDL, and SOAP. SOA requires that a service have a platform-independent interface contract. This requirement is fulfilled by XML. SOA stresses interoperability. This requirement is fulfilled by HTTP. This is why web services lie at the heart of SOA.

== Benefits of SOA ==

'''SOAs offer the following advantages over other approaches:'''

* They offer business services across the platforms.

* They provide location independence.

* Services need not be at a particular system or particular network.

* Completely loosely coupled approach.

* Authentication and authorization support at every level.

* The search and connectivity to other services is dynamic.

'''Short-term benefits of implementation:'''

* Enhances reliability.

* Reduces hardware acquisition costs.

* Leverages existing development skills.

* Accelerates movement to standards-based server and application consolidation.

* Provides a data bridge between incompatible technologies.

'''Long-term benefits of implementation:'''

* Provides the ability to build composite applications.

* Creates a self-healing infrastructure that reduces management costs.

* Provides truly real-time decision-making applications.

* Enables the compilation of a unified taxonomy of information across an enterprise and its customer and partners.

'''Benefits from the perspective of Business Value'''

* Ability to more quickly meet customer demands.

* Lower costs associated with the acquisition and maintenance of technology.

* Management of business functionality closer to the business units.

* Leverages existing investments in technology.

* Reduces reliance on expensive custom development.

== Areas in SOA Implementation where OO Concepts are used ==

As service oriented architecture gains popularity, it is starting to prove beneficial in places where OOP was inadequate. However, this does not mean an end to the OOP paradigm. Significant OOP principles are required by SOA architects to create interfaces to distributed applications.
The main areas where OO concepts come into picture are

''' 1. Interface Orientation '''
The interfaces should be at a higher level of abstraction from service implementation and should be able to provide well defined interfaces in an implementation-independent manner. There should be a comprehensive, uniform service specification with stable and well managed contracts.

''' 2. Interoperability '''
This is of prime concern to ensure seamless integration of applications in a heterogeneous environment. So they have to be interoperable, standard-based interfaces. Such technical standardization, coupled with business standardization will make SOA more effective.

''' 3. Autonomy and Modularity '''
An effective SOA architecture divides the existing architecture into autonomous sub systems. Care is to be taken that resources and functions are grouped together to ensure high cohesion and reduced runtime dependencies through a loosely coupled communication system.

= Cohesion in SOA =
'''Cohesion''', a quality to be maximized, focuses on the relationships between the activities performed by each module. There are different forms of coupling cohesion. The following three of these forms are considered safe -

* '''Functional cohesion''' occurs when a module does only one thing. Such modules that also display low coupling are highly reusable because they are self-contained and largely independent of any surrounding code.

* '''Sequential cohesion''' occurs when a module carries out several tasks, and the input of one task feeds into another, perhaps modifying the data as it passes through. A sequentially cohesive module or service is often a wrapper around other modules or services, chaining them together to perform a larger function.

* '''Communicational cohesion''' is when a module carries out multiple operations based on the same input or output data. Such cohesion often results from the desire to operate only once on a complex set of data, calculating in one pass everything that the rest of the application might possibly want to retrieve or derive from it.

In contrast to the “good” forms of cohesion, the following four forms are frowned upon:

* '''Procedural cohesion''' is similar to sequential cohesion except that the data feeding each of the tasks is different. Such cohesion often results from artificially grouping activities of an application together into catch-all functions in a misguided attempt to reduce coupling.

* '''Temporal cohesion''' occurs when a module’s tasks are related only by the time they’re carried out. Such modules cause maintenance problems if one of the tasks needs to be performed at a different time.

* '''Logical cohesion''' is a condition in which a module’s activities are grouped together because they appear to be able to share common implementations. This results in a strange or awkward interface for the module, thereby punishing all of its users, just to ease the implementer’s job.

* '''Coincidental cohesion''' represents the bottom of the cohesion barrel, in which a module’s tasks are related only by the fact that they reside together in that module.

 

= Coupling in SOA =

Coupling is a measure of interdependencies between modules, which should be minimized. Hence, quality systems tend to exhibit “loose” rather than “tight” coupling. The following forms are referred to as normal coupling -

* '''Data coupling''' occurs when modules pass data between each other, such as when a variable is passed as a parameter to a function call.

* '''Stamp coupling''' is like data coupling but with composite parameters. The difference is that the composite structure’s fields are passed somewhat invisibly. Passing a whole structure allows the called module to manipulate all fields contained therein, which can be undesirable if the module really only needs access to one or two fields.

* '''Control coupling''' occurs when one module knows something about and passes information that’s intended to control the logic of another. Such an arrangement make it harder to change the decisions, and also implies reduced module cohesion as well.

The following forms are to be avoided -

* '''Common coupling''' occurs when two modules share a common data area, such as global variables. Consider the services that share directories, registries, or databases.

* '''Content coupling''' describes the situation in which one module directly refers to another’s innards. Modern form is generally known as implementation coupling, in which one module depends on the implementation details of another. It means that changes to one module or service will almost certainly require modifications to the other.

* '''Interface coupling''' refers to the degree to which one module depends on another’s interface. Objects and packages generally offer multiple methods, and it’s not unusual for code using an object or package to depend on many or all of its methods. 

= Design Patterns in SOA =
A ‘service’ is the main design element of service oriented architecture. It encapsulates existing application logic and can be dynamically combined to form business processes. Services represent abstract software elements and/or interfaces which provide other applications with stable, reusable software functionality at a business-related level of granularity using widely applied standards. The OO design principles and design patterns which come in very handy when designing services are

''' 1. Service loose coupling '''

This design principle promotes the independent design and evolution of a service’s logic and implementation. But it still guarantees baseline interoperability with consumers that have come to rely on the service’s capabilities. There are numerous types of coupling involved in the design of a service, each of which can impact the content and granularity of its contract. Achieving the appropriate level of coupling requires that practical considerations be balanced against various service design preferences. Coupling should be such that runtime dependencies should be reduced to a minimum.

''' 2. Service Abstraction '''

Abstraction emphasizes the need to hide as much of the underlying details of a service as possible. This contributes in preserving the loosely coupled relationship. Service Abstraction also plays a significant role in the positioning and design of service compositions. Various forms of meta data come into the picture when assessing appropriate abstraction levels. The extent of abstraction applied can affect service contract granularity and can further influence the ultimate cost and effort of governing the service.

''' 3. Service Reusability '''

Reuse is a core part of typical service analysis and design processes, and also forms the basis for key service models. It emphasizes the positioning of services as enterprise resources with agnostic functional contexts. Numerous design considerations are raised to ensure that individual service capabilities are appropriately defined in relation to an agnostic service context, and to guarantee that they can facilitate the necessary reuse requirements.

''' 4. Service Autonomy '''

The principle of Service Autonomy supports the extent to which other design principles can be effectively realized in real world production environments by fostering design characteristics that increase a service’s reliability and behavioral predictability. This principle raises various issues that pertain to the design of service logic as well as the service’s actual implementation environment. Isolation levels and service normalization considerations are taken into account to achieve a suitable measure of autonomy, especially for reusable services that are frequently shared.

''' 5. Service Composability '''

As the level of sophistication and complexity in the design of a service grows, the ability to effectively compose services is a critical. Complex service compositions place demands on service design that need to be anticipated to avoid massive retro-fitting efforts. Services are expected to be capable of participating as effective composition members, regardless of whether they need to be immediately enlisted in a composition.

= Service Oriented Architecture in contrast with Enterprise Architecture =

==Similarities==
SOA and EA domains share many similarities.

* Both address similar architectural domains.

* Both are intended to closely align IT with business.

* Both use input based on business objectives.

* Both require similar strategies and planning activities.

== Differences ==
While the focus of the EA architecture domains is on the macro level, the SOA architecture domains work on a micro level. More specifically:

* EA focuses on defining business components, while SOA focuses on business services.
* EA deals with application frameworks and enterprise applications, while SOA's scope is on service modeling only.
* EA deals with enterprise-level infrastructure including servers, databases, and so on, while SOA focuses on the infrastructure that supports services, namely the Enterprise Service Bus.
* EA addresses enterprise integration patterns and when they should be used, including point-to-point integration; file transfer, and other traditional application integration approaches. SOA provides an integration approach based on using services. Though the SOA approach to integration may prove to be the most flexible and recommended approach, you should consider it as one of the approaches EA needs to define and support.

{|cellspacing="0" border="2" style="color:black; background-color:White;"
!style="width:25%"|Service Oriented Architecture
!style="width:25%"|Enterprise Architecture
|-
|Focus on ‘service’
|Focus on business components
|-
|Scope limited to service modeling
|Also focuses on Application frameworks
|-
|Focus on infrastructure providing services, ie Enterprise Service Bus
|Deals with enterprise level infrastructure components like servers, databases, etc.
|-
|Provides an integration approach based on using services
|Addresses integration patters like point-to-point integration; file transfer, and other traditional application integration approaches
|-
|} 

= Example =
SOA has had a huge effect not only on the server side but also on the clients meant for using services. A very vivid illustration of this is the ability of most modern browsers to subscribe to RSS feeds.

[[Image:Client.png|600x800px]]

Clients must have strongly constructed communications services. Any communication standard (example XML-RPC) has to be implemented on both sides to achieve proper communications.

The main controller of each client application must be capable of launching various runtime environments. This is done via launching one or more virtual machines that can interpret scripting languages or consume bytecode.

Most modern clients have some form of data persistence and state management. This usually works in conjunction with the clients’ communications services to allow the controller to use cached resources rather than attempting to synchronize states if communications are down. Additionally, rendering and media functionality specific to one or more languages is used to ensure the view of the application is built in accordance with the intentions of the application developer.

= SOA Implementation using J2EE =

Service-oriented architectures are used to implement composite applications that offer location transparency and segregation of business logic. These two key features allow replacement or modification of individual components in the composite application without affecting other components or the process as a whole. Moreover, you can independently specify alternative paths through which the various parts of the composite application exchange messages.

The J2EE platform provides web services support through the new JAX-RPC 1.1 API, which supports service endpoints based on servlets and enterprise beans. JAX-RPC 1.1 provides interoperability with web services based on the WSDL and SOAP protocols. In addition to numerous web services APIs, the J2EE 1.4 platform also features support for the WS-I Basic Profile 1.0. The WS-I Basic Profile standards allow web services to overcome the barriers of different programming languages, operating systems, and vendor platforms so that multiple applications can interact. This makes it an ideal platform to implement SOA.

Using J2EE as a development platform, a web service client can access J2EE applications as:
1. The client can access a web service created with the JAX-RPC API and at the backend, JAX-RPC uses a servlet to implement the web service.
2. A web service client can also access a stateless session bean through the service endpoint interface of that bean. Web service clients cannot access other types of enterprise beans.

[[Image:SOAJ2EE.jpg|600x600px]]

SOA can be used for internal corporate applications as well as to expose services to external clients.

The basic functional units of this architecture are:

*External clients: These can include Web-based clients, mobile clients, or clients coded in the .NET environment, Perl, or any other programming language. All of these clients send requests for various services.

*Corporate firewall: Based on its security policies corporations have firewalls between its intranet and the Internet, restricting incoming packet information.

*Web Services Gateway: It a middleware component that provides an intermediary framework between Internet and intranet environments during web service invocations. It is possible to safely externalize a web service so that it can be invoked by clients from outside the firewall. It provides security (basic authorization) on the individual methods of a web service, as well as for the gateway as a whole. Using the Web Services Gateway, a request from the client can be transformed into any messaging protocol required by your service.

*EJB web services: With the EJB 1.4 specification, web services endpoints can be modeled as stateless session beans.

*Data access interfaces: This layer is responsible for interacting with the EIS and returning data back to corresponding EJB web service methods in the format that those methods expect.

*Mainframe based Services: Existing mainframe-based services can be exposed as web services, thus revealing them to the outside world. Web service clients interact with EJB web services using the HTTP-based SOAP protocol, and the EJB methods post requests to an MQSeries queue via the JMS protocol.

= Conclusion =
Even though we have decades of experience in software development, we have yet to solve the mysteries of software complexity. As complexity grows, researchers find more innovative ways to answer the call. SOA, in combination with web services, is the latest answer. Application integration is one of the major issues companies face today; SOA can solve that. System availability, reliability, and scalability continue to bite companies today; SOA addresses these issues. Given today's requirements, SOA is the best scalable solution for application architecture.

= References =
[1] M. Page-Jones, The Practical Guide to Structured Systems Design, 2nd ed., Prentice-Hall, 1988.

[2]. J. Martin and C. McClure, Structured Techniques for Computing, Prentice-Hall, 1985.

[3] Bell, Michael, "Introduction to Service-Oriented Modeling". Service-Oriented Modeling: Service Analysis, Design, and Architecture. Wiley & Sons. pp. 3, 2008.

[4] Channabasavaiah, Holley and Tuggle, [http://www-128.ibm.com/developerworks/library/ws-migratesoa/ Migrating to a service-oriented architecture], IBM DeveloperWorks, 16 December 2003.

[5] ''Enterprise SOA''. Prentice Hall, 2005

[6] Brayan Zimmerli [http://www.brayan.com/projects/BenefitsOfSOA/default.htm Business Benefits of SOA], University of Applied Science of Northwestern Switzerland, School of Business, 11 November 2009

[7] [http://blogs.zdnet.com/service-oriented/?p=2306 "SOA services still too constrained by applications they represent"]. zdnet.com. 2009-06-26.

[8] Erl, Thomas. [http://www.serviceorientation.org/ Serviceorientation.org] – About the Principles, 2005-2006

[9] [http://www.soa-manifesto.org/ SOA Manifesto Official Website] Date Accessed: 25 November 2010.

CSC/ECE 517 Fall 2010/ch6 6j SO

2010-11-26T04:25:54Z

Solo2012:

= Service-oriented architecture =

== Introduction ==

SOA (service-oriented architecture) has become a buzzword of late. The World Wide Web Consortium (W3C) refers to SOA as 'A set of components which can be invoked, and whose interface descriptions can be published and discovered'. Only a technical person can understand this definition. A simplified version of this definition would be -

''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. The combination of services - internal and external to an organization - makes up a service-oriented architecture.''

Although the concepts behind SOA have been around for over a decade now, SOA has gained extreme popularity of late due to web services. Before we dive into the details, let us step back and examine the context for the evolution of SOA. To do that, we have to simply look at the challenges faced by the developers over the past few decades and observe the solutions that have been proposed to solve their problems.

== The Problem ==

Early programmers soon realized that writing software was becoming way too complex. They realised the need of reusing some of the code they were rewriting. Researchers had a new mantra: go-to considered harmful. They introduced the concept of modular design. Modular design deals with the use of routines, sub routines and functions in order to organize and execute specific sets of instructions which helped programmers to reuse their code. This concept was again OK for smaller programs. But as the size and the complexity increased this started to create a maintenance nightmare. When a bug was discovered in a function somewhere, they had to track down all of the applications that used the function and modify the code to reflect the fix. Also, here we lay stress only on the steps of execution, but we are hardly bothered about the data for which all these has been done. This laid the groundwork for thinking new concepts, which would give absolute data security and OOPs evolved.

To solve these problems researchers proposed object-oriented software. Again, as software complexity grew, developers realized that developing and maintaining software was complex and they wanted a way to reuse and maintain functionality, not just code. Researchers offered yet another abstraction layer to handle this complexity -- component-based software. Component-based software is/was a good solution for reuse and maintenance, but it doesn't address all of the complexities developers are faced with today. Today, we face complex issues like distributed software, application integration, varying platforms, varying protocols, various devices, the Internet, etc. Today's software has to be equipped to answer the call for all of the above. In short, SOA (along with web services) provides a solution to all of the above. By adopting a SOA, you eliminate the headaches of protocol and platforms and your applications integrate seamlessly.

== Key Components of SOA ==

The first step in learning something new is to understand its vocabulary. In the context of SOA, we have the terms service, message, dynamic discovery, and web services. Each of these plays an essential role in SOA.

=== Service ===

A service in SOA is an exposed piece of functionality with three properties:

1. The interface contract to the service is platform-independent.

2. The service can be dynamically located and invoked.

3. The service is self-contained. That is, the service maintains its own state.

A platform-independent interface contract implies that a client from anywhere, on any OS, and in any language, can consume the service. Dynamic discovery hints that a discovery service (e.g., a directory service) is available. The directory service enables a look-up mechanism where consumers can go to find a service based on some criteria. For example, if some one was looking for a credit-card authorization service, he might query the directory service to find a list of service providers that could authorize a credit card for a fee. Based on the fee, he would select a service (see Figure below). The last property of a service is that the service be self-contained.

[[Image:SOA.gif|400x500px]]

=== Message ===

Service providers and consumers communicate via messages. Services expose an interface contract. This contract defines the behavior of the service and the messages they accept and return. Because the interface contract is platform- and language-independent, the technology used to define messages must also be agnostic to any specific platform/language. Therefore, messages are typically constructed using XML documents that conform to XML schema. XML provides all of the functionality, granularity, and scalability required by messages. That is, for consumers and providers to effectively communicate, they need a non-restrictive type of system to clearly define messages; XML provides this. Because consumers and providers communicate via messages, the structure and design of messages should not be taken lightly. Messages need to be implemented using a technology that supports the scalability requirements of services. Having to redesign messages will break the interface to providers, which can prove to be costly.

=== Dynamic Discovery ===

Dynamic discovery is an important piece of SOA. At a high level, SOA is composed of three core pieces: service providers, service consumers, and the directory service. The role of providers and consumers are apparent, but the role of the directory service needs some explanation. The directory service is an intermediary between providers and consumers. Providers register with the directory service and consumers query the directory service to find service providers. Most directory services typically organize services based on criteria and categorize them. Consumers can then use the directory services' search capabilities to find providers. Embedding a directory service within SOA accomplishes the following:

1. Scalability of services; you can add services incrementally.

2. Decouples consumers from providers.

3. Allows for hot updates of services.

4. Provides a look-up service for consumers.

5. Allows consumers to choose between providers at runtime rather than hard-coding a single provider.

=== Web Service ===

Although the concepts behind SOA were established long before web services came along, web services play a major role in a SOA. This is because web services are built on top of well-known and platform-independent protocols. These protocols include HTTP, XML, UDDI, WSDL, and SOAP. It is the combination of these protocols that make web services so attractive. Moreover, it is these protocols that fulfill the key requirements of a SOA. That is, a SOA requires that a service be dynamically discoverable and invokeable. This requirement is fulfilled by UDDI, WSDL, and SOAP. SOA requires that a service have a platform-independent interface contract. This requirement is fulfilled by XML. SOA stresses interoperability. This requirement is fulfilled by HTTP. This is why web services lie at the heart of SOA.

== Benefits of SOA ==

'''SOAs offer the following advantages over other approaches:'''

* They offer business services across the platforms.

* They provide location independence.

* Services need not be at a particular system or particular network.

* Completely loosely coupled approach.

* Authentication and authorization support at every level.

* The search and connectivity to other services is dynamic.

'''Short-term benefits of implementation:'''

* Enhances reliability.

* Reduces hardware acquisition costs.

* Leverages existing development skills.

* Accelerates movement to standards-based server and application consolidation.

* Provides a data bridge between incompatible technologies.

'''Long-term benefits of implementation:'''

* Provides the ability to build composite applications.

* Creates a self-healing infrastructure that reduces management costs.

* Provides truly real-time decision-making applications.

* Enables the compilation of a unified taxonomy of information across an enterprise and its customer and partners.

'''Benefits from the perspective of Business Value'''

* Ability to more quickly meet customer demands.

* Lower costs associated with the acquisition and maintenance of technology.

* Management of business functionality closer to the business units.

* Leverages existing investments in technology.

* Reduces reliance on expensive custom development.

== Areas in SOA Implementation where OO Concepts are used ==

As service oriented architecture gains popularity, it is starting to prove beneficial in places where OOP was inadequate. However, this does not mean an end to the OOP paradigm. Significant OOP principles are required by SOA architects to create interfaces to distributed applications.
The main areas where OO concepts come into picture are

''' 1. Interface Orientation '''
The interfaces should be at a higher level of abstraction from service implementation and should be able to provide well defined interfaces in an implementation-independent manner. There should be a comprehensive, uniform service specification with stable and well managed contracts.

''' 2. Interoperability '''
This is of prime concern to ensure seamless integration of applications in a heterogeneous environment. So they have to be interoperable, standard-based interfaces. Such technical standardization, coupled with business standardization will make SOA more effective.

''' 3. Autonomy and Modularity '''
An effective SOA architecture divides the existing architecture into autonomous sub systems. Care is to be taken that resources and functions are grouped together to ensure high cohesion and reduced runtime dependencies through a loosely coupled communication system.

= Cohesion in SOA =
'''Cohesion''', a quality to be maximized, focuses on the relationships between the activities performed by each module. There are different forms of coupling cohesion. The following three of these forms are considered safe -

* '''Functional cohesion''' occurs when a module does only one thing. Such modules that also display low coupling are highly reusable because they are self-contained and largely independent of any surrounding code.

* '''Sequential cohesion''' occurs when a module carries out several tasks, and the input of one task feeds into another, perhaps modifying the data as it passes through. A sequentially cohesive module or service is often a wrapper around other modules or services, chaining them together to perform a larger function.

* '''Communicational cohesion''' is when a module carries out multiple operations based on the same input or output data. Such cohesion often results from the desire to operate only once on a complex set of data, calculating in one pass everything that the rest of the application might possibly want to retrieve or derive from it.

In contrast to the “good” forms of cohesion, the following four forms are frowned upon:

* '''Procedural cohesion''' is similar to sequential cohesion except that the data feeding each of the tasks is different. Such cohesion often results from artificially grouping activities of an application together into catch-all functions in a misguided attempt to reduce coupling.

* '''Temporal cohesion''' occurs when a module’s tasks are related only by the time they’re carried out. Such modules cause maintenance problems if one of the tasks needs to be performed at a different time.

* '''Logical cohesion''' is a condition in which a module’s activities are grouped together because they appear to be able to share common implementations. This results in a strange or awkward interface for the module, thereby punishing all of its users, just to ease the implementer’s job.

* '''Coincidental cohesion''' represents the bottom of the cohesion barrel, in which a module’s tasks are related only by the fact that they reside together in that module.

 

= Coupling in SOA =

Coupling is a measure of interdependencies between modules, which should be minimized. Hence, quality systems tend to exhibit “loose” rather than “tight” coupling. The following forms are referred to as normal coupling -

* '''Data coupling''' occurs when modules pass data between each other, such as when a variable is passed as a parameter to a function call.

* '''Stamp coupling''' is like data coupling but with composite parameters. The difference is that the composite structure’s fields are passed somewhat invisibly. Passing a whole structure allows the called module to manipulate all fields contained therein, which can be undesirable if the module really only needs access to one or two fields.

* '''Control coupling''' occurs when one module knows something about and passes information that’s intended to control the logic of another. Such an arrangement make it harder to change the decisions, and also implies reduced module cohesion as well.

The following forms are to be avoided -

* '''Common coupling''' occurs when two modules share a common data area, such as global variables. Consider the services that share directories, registries, or databases.

* '''Content coupling''' describes the situation in which one module directly refers to another’s innards. Modern form is generally known as implementation coupling, in which one module depends on the implementation details of another. It means that changes to one module or service will almost certainly require modifications to the other.

* '''Interface coupling''' refers to the degree to which one module depends on another’s interface. Objects and packages generally offer multiple methods, and it’s not unusual for code using an object or package to depend on many or all of its methods. 

= Design Patterns in SOA =
A ‘service’ is the main design element of service oriented architecture. It encapsulates existing application logic and can be dynamically combined to form business processes. Services represent abstract software elements and/or interfaces which provide other applications with stable, reusable software functionality at a business-related level of granularity using widely applied standards. The OO design principles and design patterns which come in very handy when designing services are

''' 1. Service loose coupling '''

This design principle promotes the independent design and evolution of a service’s logic and implementation. But it still guarantees baseline interoperability with consumers that have come to rely on the service’s capabilities. There are numerous types of coupling involved in the design of a service, each of which can impact the content and granularity of its contract. Achieving the appropriate level of coupling requires that practical considerations be balanced against various service design preferences. Coupling should be such that runtime dependencies should be reduced to a minimum.

''' 2. Service Abstraction '''

Abstraction emphasizes the need to hide as much of the underlying details of a service as possible. This contributes in preserving the loosely coupled relationship. Service Abstraction also plays a significant role in the positioning and design of service compositions. Various forms of meta data come into the picture when assessing appropriate abstraction levels. The extent of abstraction applied can affect service contract granularity and can further influence the ultimate cost and effort of governing the service.

''' 3. Service Reusability '''

Reuse is a core part of typical service analysis and design processes, and also forms the basis for key service models. It emphasizes the positioning of services as enterprise resources with agnostic functional contexts. Numerous design considerations are raised to ensure that individual service capabilities are appropriately defined in relation to an agnostic service context, and to guarantee that they can facilitate the necessary reuse requirements.

''' 4. Service Autonomy '''

The principle of Service Autonomy supports the extent to which other design principles can be effectively realized in real world production environments by fostering design characteristics that increase a service’s reliability and behavioral predictability. This principle raises various issues that pertain to the design of service logic as well as the service’s actual implementation environment. Isolation levels and service normalization considerations are taken into account to achieve a suitable measure of autonomy, especially for reusable services that are frequently shared.

''' 5. Service Composability '''

As the level of sophistication and complexity in the design of a service grows, the ability to effectively compose services is a critical. Complex service compositions place demands on service design that need to be anticipated to avoid massive retro-fitting efforts. Services are expected to be capable of participating as effective composition members, regardless of whether they need to be immediately enlisted in a composition.

= Service Oriented Architecture in contrast with Enterprise Architecture =

==Similarities==
SOA and EA domains share many similarities.

* Both address similar architectural domains.

* Both are intended to closely align IT with business.

* Both use input based on business objectives.

* Both require similar strategies and planning activities.

== Differences ==
While the focus of the EA architecture domains is on the macro level, the SOA architecture domains work on a micro level. More specifically:

* EA focuses on defining business components, while SOA focuses on business services.
* EA deals with application frameworks and enterprise applications, while SOA's scope is on service modeling only.
* EA deals with enterprise-level infrastructure including servers, databases, and so on, while SOA focuses on the infrastructure that supports services, namely the Enterprise Service Bus.
* EA addresses enterprise integration patterns and when they should be used, including point-to-point integration; file transfer, and other traditional application integration approaches. SOA provides an integration approach based on using services. Though the SOA approach to integration may prove to be the most flexible and recommended approach, you should consider it as one of the approaches EA needs to define and support.

{|cellspacing="0" border="2" style="color:black; background-color:White;"
!style="width:25%"|Service Oriented Architecture
!style="width:25%"|Enterprise Architecture
|-
|Focus on ‘service’
|Focus on business components
|-
|Scope limited to service modeling
|Also focuses on Application frameworks
|-
|Focus on infrastructure providing services, ie Enterprise Service Bus
|Deals with enterprise level infrastructure components like servers, databases, etc.
|-
|Provides an integration approach based on using services
|Addresses integration patters like point-to-point integration; file transfer, and other traditional application integration approaches
|-
|} 

= Example =
SOA has had a huge effect not only on the server side but also on the clients meant for using services. A very vivid illustration of this is the ability of most modern browsers to subscribe to RSS feeds.

[[Image:Client.png|600x800px]]

Clients must have strongly constructed communications services. Any communication standard (example XML-RPC) has to be implemented on both sides to achieve proper communications.

The main controller of each client application must be capable of launching various runtime environments. This is done via launching one or more virtual machines that can interpret scripting languages or consume bytecode.

Most modern clients have some form of data persistence and state management. This usually works in conjunction with the clients’ communications services to allow the controller to use cached resources rather than attempting to synchronize states if communications are down. Additionally, rendering and media functionality specific to one or more languages is used to ensure the view of the application is built in accordance with the intentions of the application developer.

= SOA Implementation using J2EE =

Service-oriented architectures are used to implement composite applications that offer location transparency and segregation of business logic. These two key features allow replacement or modification of individual components in the composite application without affecting other components or the process as a whole. Moreover, you can independently specify alternative paths through which the various parts of the composite application exchange messages.

The J2EE platform provides web services support through the new JAX-RPC 1.1 API, which supports service endpoints based on servlets and enterprise beans. JAX-RPC 1.1 provides interoperability with web services based on the WSDL and SOAP protocols. In addition to numerous web services APIs, the J2EE 1.4 platform also features support for the WS-I Basic Profile 1.0. The WS-I Basic Profile standards allow web services to overcome the barriers of different programming languages, operating systems, and vendor platforms so that multiple applications can interact. This makes it an ideal platform to implement SOA.

Using J2EE as a development platform, a web service client can access J2EE applications as:
1. The client can access a web service created with the JAX-RPC API and at the backend, JAX-RPC uses a servlet to implement the web service.
2. A web service client can also access a stateless session bean through the service endpoint interface of that bean. Web service clients cannot access other types of enterprise beans.

[[Image:SOAJ2EE.jpg|600x600px]]

= Conclusion =
Even though we have decades of experience in software development, we have yet to solve the mysteries of software complexity. As complexity grows, researchers find more innovative ways to answer the call. SOA, in combination with web services, is the latest answer. Application integration is one of the major issues companies face today; SOA can solve that. System availability, reliability, and scalability continue to bite companies today; SOA addresses these issues. Given today's requirements, SOA is the best scalable solution for application architecture.

= References =
[1] M. Page-Jones, The Practical Guide to Structured Systems Design, 2nd ed., Prentice-Hall, 1988.

[2]. J. Martin and C. McClure, Structured Techniques for Computing, Prentice-Hall, 1985.

[3] Bell, Michael, "Introduction to Service-Oriented Modeling". Service-Oriented Modeling: Service Analysis, Design, and Architecture. Wiley & Sons. pp. 3, 2008.

[4] Channabasavaiah, Holley and Tuggle, [http://www-128.ibm.com/developerworks/library/ws-migratesoa/ Migrating to a service-oriented architecture], IBM DeveloperWorks, 16 December 2003.

[5] ''Enterprise SOA''. Prentice Hall, 2005

[6] Brayan Zimmerli [http://www.brayan.com/projects/BenefitsOfSOA/default.htm Business Benefits of SOA], University of Applied Science of Northwestern Switzerland, School of Business, 11 November 2009

[7] [http://blogs.zdnet.com/service-oriented/?p=2306 "SOA services still too constrained by applications they represent"]. zdnet.com. 2009-06-26.

[8] Erl, Thomas. [http://www.serviceorientation.org/ Serviceorientation.org] – About the Principles, 2005-2006

[9] [http://www.soa-manifesto.org/ SOA Manifesto Official Website] Date Accessed: 25 November 2010.

File:SOAJ2EE.jpg

2010-11-26T04:25:14Z

Solo2012:

CSC/ECE 517 Fall 2010/ch6 6j SO

2010-11-26T04:23:29Z

Solo2012:

= Service-oriented architecture =

== Introduction ==

SOA (service-oriented architecture) has become a buzzword of late. The World Wide Web Consortium (W3C) refers to SOA as 'A set of components which can be invoked, and whose interface descriptions can be published and discovered'. Only a technical person can understand this definition. A simplified version of this definition would be -

''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. The combination of services - internal and external to an organization - makes up a service-oriented architecture.''

Although the concepts behind SOA have been around for over a decade now, SOA has gained extreme popularity of late due to web services. Before we dive into the details, let us step back and examine the context for the evolution of SOA. To do that, we have to simply look at the challenges faced by the developers over the past few decades and observe the solutions that have been proposed to solve their problems.

== The Problem ==

Early programmers soon realized that writing software was becoming way too complex. They realised the need of reusing some of the code they were rewriting. Researchers had a new mantra: go-to considered harmful. They introduced the concept of modular design. Modular design deals with the use of routines, sub routines and functions in order to organize and execute specific sets of instructions which helped programmers to reuse their code. This concept was again OK for smaller programs. But as the size and the complexity increased this started to create a maintenance nightmare. When a bug was discovered in a function somewhere, they had to track down all of the applications that used the function and modify the code to reflect the fix. Also, here we lay stress only on the steps of execution, but we are hardly bothered about the data for which all these has been done. This laid the groundwork for thinking new concepts, which would give absolute data security and OOPs evolved.

To solve these problems researchers proposed object-oriented software. Again, as software complexity grew, developers realized that developing and maintaining software was complex and they wanted a way to reuse and maintain functionality, not just code. Researchers offered yet another abstraction layer to handle this complexity -- component-based software. Component-based software is/was a good solution for reuse and maintenance, but it doesn't address all of the complexities developers are faced with today. Today, we face complex issues like distributed software, application integration, varying platforms, varying protocols, various devices, the Internet, etc. Today's software has to be equipped to answer the call for all of the above. In short, SOA (along with web services) provides a solution to all of the above. By adopting a SOA, you eliminate the headaches of protocol and platforms and your applications integrate seamlessly.

== Key Components of SOA ==

The first step in learning something new is to understand its vocabulary. In the context of SOA, we have the terms service, message, dynamic discovery, and web services. Each of these plays an essential role in SOA.

=== Service ===

A service in SOA is an exposed piece of functionality with three properties:

1. The interface contract to the service is platform-independent.

2. The service can be dynamically located and invoked.

3. The service is self-contained. That is, the service maintains its own state.

A platform-independent interface contract implies that a client from anywhere, on any OS, and in any language, can consume the service. Dynamic discovery hints that a discovery service (e.g., a directory service) is available. The directory service enables a look-up mechanism where consumers can go to find a service based on some criteria. For example, if some one was looking for a credit-card authorization service, he might query the directory service to find a list of service providers that could authorize a credit card for a fee. Based on the fee, he would select a service (see Figure below). The last property of a service is that the service be self-contained.

[[Image:SOA.gif|400x500px]]

=== Message ===

Service providers and consumers communicate via messages. Services expose an interface contract. This contract defines the behavior of the service and the messages they accept and return. Because the interface contract is platform- and language-independent, the technology used to define messages must also be agnostic to any specific platform/language. Therefore, messages are typically constructed using XML documents that conform to XML schema. XML provides all of the functionality, granularity, and scalability required by messages. That is, for consumers and providers to effectively communicate, they need a non-restrictive type of system to clearly define messages; XML provides this. Because consumers and providers communicate via messages, the structure and design of messages should not be taken lightly. Messages need to be implemented using a technology that supports the scalability requirements of services. Having to redesign messages will break the interface to providers, which can prove to be costly.

=== Dynamic Discovery ===

Dynamic discovery is an important piece of SOA. At a high level, SOA is composed of three core pieces: service providers, service consumers, and the directory service. The role of providers and consumers are apparent, but the role of the directory service needs some explanation. The directory service is an intermediary between providers and consumers. Providers register with the directory service and consumers query the directory service to find service providers. Most directory services typically organize services based on criteria and categorize them. Consumers can then use the directory services' search capabilities to find providers. Embedding a directory service within SOA accomplishes the following:

1. Scalability of services; you can add services incrementally.

2. Decouples consumers from providers.

3. Allows for hot updates of services.

4. Provides a look-up service for consumers.

5. Allows consumers to choose between providers at runtime rather than hard-coding a single provider.

=== Web Service ===

Although the concepts behind SOA were established long before web services came along, web services play a major role in a SOA. This is because web services are built on top of well-known and platform-independent protocols. These protocols include HTTP, XML, UDDI, WSDL, and SOAP. It is the combination of these protocols that make web services so attractive. Moreover, it is these protocols that fulfill the key requirements of a SOA. That is, a SOA requires that a service be dynamically discoverable and invokeable. This requirement is fulfilled by UDDI, WSDL, and SOAP. SOA requires that a service have a platform-independent interface contract. This requirement is fulfilled by XML. SOA stresses interoperability. This requirement is fulfilled by HTTP. This is why web services lie at the heart of SOA.

== Benefits of SOA ==

'''SOAs offer the following advantages over other approaches:'''

* They offer business services across the platforms.

* They provide location independence.

* Services need not be at a particular system or particular network.

* Completely loosely coupled approach.

* Authentication and authorization support at every level.

* The search and connectivity to other services is dynamic.

'''Short-term benefits of implementation:'''

* Enhances reliability.

* Reduces hardware acquisition costs.

* Leverages existing development skills.

* Accelerates movement to standards-based server and application consolidation.

* Provides a data bridge between incompatible technologies.

'''Long-term benefits of implementation:'''

* Provides the ability to build composite applications.

* Creates a self-healing infrastructure that reduces management costs.

* Provides truly real-time decision-making applications.

* Enables the compilation of a unified taxonomy of information across an enterprise and its customer and partners.

'''Benefits from the perspective of Business Value'''

* Ability to more quickly meet customer demands.

* Lower costs associated with the acquisition and maintenance of technology.

* Management of business functionality closer to the business units.

* Leverages existing investments in technology.

* Reduces reliance on expensive custom development.

== Areas in SOA Implementation where OO Concepts are used ==

As service oriented architecture gains popularity, it is starting to prove beneficial in places where OOP was inadequate. However, this does not mean an end to the OOP paradigm. Significant OOP principles are required by SOA architects to create interfaces to distributed applications.
The main areas where OO concepts come into picture are

''' 1. Interface Orientation '''
The interfaces should be at a higher level of abstraction from service implementation and should be able to provide well defined interfaces in an implementation-independent manner. There should be a comprehensive, uniform service specification with stable and well managed contracts.

''' 2. Interoperability '''
This is of prime concern to ensure seamless integration of applications in a heterogeneous environment. So they have to be interoperable, standard-based interfaces. Such technical standardization, coupled with business standardization will make SOA more effective.

''' 3. Autonomy and Modularity '''
An effective SOA architecture divides the existing architecture into autonomous sub systems. Care is to be taken that resources and functions are grouped together to ensure high cohesion and reduced runtime dependencies through a loosely coupled communication system.

= Cohesion in SOA =
'''Cohesion''', a quality to be maximized, focuses on the relationships between the activities performed by each module. There are different forms of coupling cohesion. The following three of these forms are considered safe -

* '''Functional cohesion''' occurs when a module does only one thing. Such modules that also display low coupling are highly reusable because they are self-contained and largely independent of any surrounding code.

* '''Sequential cohesion''' occurs when a module carries out several tasks, and the input of one task feeds into another, perhaps modifying the data as it passes through. A sequentially cohesive module or service is often a wrapper around other modules or services, chaining them together to perform a larger function.

* '''Communicational cohesion''' is when a module carries out multiple operations based on the same input or output data. Such cohesion often results from the desire to operate only once on a complex set of data, calculating in one pass everything that the rest of the application might possibly want to retrieve or derive from it.

In contrast to the “good” forms of cohesion, the following four forms are frowned upon:

* '''Procedural cohesion''' is similar to sequential cohesion except that the data feeding each of the tasks is different. Such cohesion often results from artificially grouping activities of an application together into catch-all functions in a misguided attempt to reduce coupling.

* '''Temporal cohesion''' occurs when a module’s tasks are related only by the time they’re carried out. Such modules cause maintenance problems if one of the tasks needs to be performed at a different time.

* '''Logical cohesion''' is a condition in which a module’s activities are grouped together because they appear to be able to share common implementations. This results in a strange or awkward interface for the module, thereby punishing all of its users, just to ease the implementer’s job.

* '''Coincidental cohesion''' represents the bottom of the cohesion barrel, in which a module’s tasks are related only by the fact that they reside together in that module.

 

= Coupling in SOA =

Coupling is a measure of interdependencies between modules, which should be minimized. Hence, quality systems tend to exhibit “loose” rather than “tight” coupling. The following forms are referred to as normal coupling -

* '''Data coupling''' occurs when modules pass data between each other, such as when a variable is passed as a parameter to a function call.

* '''Stamp coupling''' is like data coupling but with composite parameters. The difference is that the composite structure’s fields are passed somewhat invisibly. Passing a whole structure allows the called module to manipulate all fields contained therein, which can be undesirable if the module really only needs access to one or two fields.

* '''Control coupling''' occurs when one module knows something about and passes information that’s intended to control the logic of another. Such an arrangement make it harder to change the decisions, and also implies reduced module cohesion as well.

The following forms are to be avoided -

* '''Common coupling''' occurs when two modules share a common data area, such as global variables. Consider the services that share directories, registries, or databases.

* '''Content coupling''' describes the situation in which one module directly refers to another’s innards. Modern form is generally known as implementation coupling, in which one module depends on the implementation details of another. It means that changes to one module or service will almost certainly require modifications to the other.

* '''Interface coupling''' refers to the degree to which one module depends on another’s interface. Objects and packages generally offer multiple methods, and it’s not unusual for code using an object or package to depend on many or all of its methods. 

= Design Patterns in SOA =
A ‘service’ is the main design element of service oriented architecture. It encapsulates existing application logic and can be dynamically combined to form business processes. Services represent abstract software elements and/or interfaces which provide other applications with stable, reusable software functionality at a business-related level of granularity using widely applied standards. The OO design principles and design patterns which come in very handy when designing services are

''' 1. Service loose coupling '''

This design principle promotes the independent design and evolution of a service’s logic and implementation. But it still guarantees baseline interoperability with consumers that have come to rely on the service’s capabilities. There are numerous types of coupling involved in the design of a service, each of which can impact the content and granularity of its contract. Achieving the appropriate level of coupling requires that practical considerations be balanced against various service design preferences. Coupling should be such that runtime dependencies should be reduced to a minimum.

''' 2. Service Abstraction '''

Abstraction emphasizes the need to hide as much of the underlying details of a service as possible. This contributes in preserving the loosely coupled relationship. Service Abstraction also plays a significant role in the positioning and design of service compositions. Various forms of meta data come into the picture when assessing appropriate abstraction levels. The extent of abstraction applied can affect service contract granularity and can further influence the ultimate cost and effort of governing the service.

''' 3. Service Reusability '''

Reuse is a core part of typical service analysis and design processes, and also forms the basis for key service models. It emphasizes the positioning of services as enterprise resources with agnostic functional contexts. Numerous design considerations are raised to ensure that individual service capabilities are appropriately defined in relation to an agnostic service context, and to guarantee that they can facilitate the necessary reuse requirements.

''' 4. Service Autonomy '''

The principle of Service Autonomy supports the extent to which other design principles can be effectively realized in real world production environments by fostering design characteristics that increase a service’s reliability and behavioral predictability. This principle raises various issues that pertain to the design of service logic as well as the service’s actual implementation environment. Isolation levels and service normalization considerations are taken into account to achieve a suitable measure of autonomy, especially for reusable services that are frequently shared.

''' 5. Service Composability '''

As the level of sophistication and complexity in the design of a service grows, the ability to effectively compose services is a critical. Complex service compositions place demands on service design that need to be anticipated to avoid massive retro-fitting efforts. Services are expected to be capable of participating as effective composition members, regardless of whether they need to be immediately enlisted in a composition.

= Service Oriented Architecture in contrast with Enterprise Architecture =

==Similarities==
SOA and EA domains share many similarities.

* Both address similar architectural domains.

* Both are intended to closely align IT with business.

* Both use input based on business objectives.

* Both require similar strategies and planning activities.

== Differences ==
While the focus of the EA architecture domains is on the macro level, the SOA architecture domains work on a micro level. More specifically:

* EA focuses on defining business components, while SOA focuses on business services.
* EA deals with application frameworks and enterprise applications, while SOA's scope is on service modeling only.
* EA deals with enterprise-level infrastructure including servers, databases, and so on, while SOA focuses on the infrastructure that supports services, namely the Enterprise Service Bus.
* EA addresses enterprise integration patterns and when they should be used, including point-to-point integration; file transfer, and other traditional application integration approaches. SOA provides an integration approach based on using services. Though the SOA approach to integration may prove to be the most flexible and recommended approach, you should consider it as one of the approaches EA needs to define and support.

{|cellspacing="0" border="2" style="color:black; background-color:White;"
!style="width:25%"|Service Oriented Architecture
!style="width:25%"|Enterprise Architecture
|-
|Focus on ‘service’
|Focus on business components
|-
|Scope limited to service modeling
|Also focuses on Application frameworks
|-
|Focus on infrastructure providing services, ie Enterprise Service Bus
|Deals with enterprise level infrastructure components like servers, databases, etc.
|-
|Provides an integration approach based on using services
|Addresses integration patters like point-to-point integration; file transfer, and other traditional application integration approaches
|-
|} 

= Example =
SOA has had a huge effect not only on the server side but also on the clients meant for using services. A very vivid illustration of this is the ability of most modern browsers to subscribe to RSS feeds.

[[Image:Client.png|600x800px]]

Clients must have strongly constructed communications services. Any communication standard (example XML-RPC) has to be implemented on both sides to achieve proper communications.

The main controller of each client application must be capable of launching various runtime environments. This is done via launching one or more virtual machines that can interpret scripting languages or consume bytecode.

Most modern clients have some form of data persistence and state management. This usually works in conjunction with the clients’ communications services to allow the controller to use cached resources rather than attempting to synchronize states if communications are down. Additionally, rendering and media functionality specific to one or more languages is used to ensure the view of the application is built in accordance with the intentions of the application developer.

= SOA Implementation using J2EE =

Service-oriented architectures are used to implement composite applications that offer location transparency and segregation of business logic. These two key features allow replacement or modification of individual components in the composite application without affecting other components or the process as a whole. Moreover, you can independently specify alternative paths through which the various parts of the composite application exchange messages.

The J2EE platform provides web services support through the new JAX-RPC 1.1 API, which supports service endpoints based on servlets and enterprise beans. JAX-RPC 1.1 provides interoperability with web services based on the WSDL and SOAP protocols. In addition to numerous web services APIs, the J2EE 1.4 platform also features support for the WS-I Basic Profile 1.0. The WS-I Basic Profile standards allow web services to overcome the barriers of different programming languages, operating systems, and vendor platforms so that multiple applications can interact. This makes it an ideal platform to implement SOA.

Using J2EE as a development platform, a web service client can access J2EE applications as:
1. The client can access a web service created with the JAX-RPC API and at the backend, JAX-RPC uses a servlet to implement the web service.
2. A web service client can also access a stateless session bean through the service endpoint interface of that bean. Web service clients cannot access other types of enterprise beans.

[[Image:SOA.jpg|600x600px]]

= Conclusion =
Even though we have decades of experience in software development, we have yet to solve the mysteries of software complexity. As complexity grows, researchers find more innovative ways to answer the call. SOA, in combination with web services, is the latest answer. Application integration is one of the major issues companies face today; SOA can solve that. System availability, reliability, and scalability continue to bite companies today; SOA addresses these issues. Given today's requirements, SOA is the best scalable solution for application architecture.

= References =
[1] M. Page-Jones, The Practical Guide to Structured Systems Design, 2nd ed., Prentice-Hall, 1988.

[2]. J. Martin and C. McClure, Structured Techniques for Computing, Prentice-Hall, 1985.

[3] Bell, Michael, "Introduction to Service-Oriented Modeling". Service-Oriented Modeling: Service Analysis, Design, and Architecture. Wiley & Sons. pp. 3, 2008.

[4] Channabasavaiah, Holley and Tuggle, [http://www-128.ibm.com/developerworks/library/ws-migratesoa/ Migrating to a service-oriented architecture], IBM DeveloperWorks, 16 December 2003.

[5] ''Enterprise SOA''. Prentice Hall, 2005

[6] Brayan Zimmerli [http://www.brayan.com/projects/BenefitsOfSOA/default.htm Business Benefits of SOA], University of Applied Science of Northwestern Switzerland, School of Business, 11 November 2009

[7] [http://blogs.zdnet.com/service-oriented/?p=2306 "SOA services still too constrained by applications they represent"]. zdnet.com. 2009-06-26.

[8] Erl, Thomas. [http://www.serviceorientation.org/ Serviceorientation.org] – About the Principles, 2005-2006

[9] [http://www.soa-manifesto.org/ SOA Manifesto Official Website] Date Accessed: 25 November 2010.

CSC/ECE 517 Fall 2010/ch6 6j SO

2010-11-18T03:46:32Z

Solo2012:

= Service-oriented architecture =

== Introduction ==

SOA (service-oriented architecture) has become a buzzword of late. The World Wide Web Consortium (W3C) refers to SOA as 'A set of components which can be invoked, and whose interface descriptions can be published and discovered'. Although the concepts behind SOA have been around for over a decade now, SOA has gained extreme popularity of late due to web services. Before we dive in and talk about what SOA is and what the essentials behind SOA are, it is a useful first step to look back at the evolution of SOA. To do that, we have to simply look at the challenges developers have faced over the past few decades and observe the solutions that have been proposed to solve their problems.

== The Problem ==

Early programmers realized that writing software was becoming more and more complex. They needed a better way to reuse some of the code that they were rewriting. When researchers took notice of this, they introduced the concept of modular design. With modular design principles, programmers could write subroutines and functions and reuse their code. This was great for a while. Later, developers started to see that they were cutting and pasting their modules into other applications and that this started to create a maintenance nightmare; when a bug was discovered in a function somewhere, they had to track down all of the applications that used the function and modify the code to reflect the fix. After the fix, the deployment nightmare began. Developers didn't like that; they needed a higher level of abstraction.

Researchers proposed classes and object-oriented software to solve this, and many more, problems. Again, as software complexity grew, developers started to see that developing and maintaining software was complex and they wanted a way to reuse and maintain functionality, not just code. Researchers offered yet another abstraction layer to handle this complexity -- component-based software. Component-based software is/was a good solution for reuse and maintenance, but it doesn't address all of the complexities developers are faced with today. Today, we face complex issues like distributed software, application integration, varying platforms, varying protocols, various devices, the Internet, etc. Today's software has to be equipped to answer the call for all of the above. In short, SOA (along with web services) provides a solution to all of the above. By adopting a SOA, you eliminate the headaches of protocol and platforms and your applications integrate seamlessly.

== Key Components of SOA ==

The first step in learning something new is to understand its vocabulary. In the context of SOA, we have the terms service, message, dynamic discovery, and web services. Each of these plays an essential role in SOA.

=== Service ===

A service in SOA is an exposed piece of functionality with three properties:

1. The interface contract to the service is platform-independent.

2. The service can be dynamically located and invoked.

3. The service is self-contained. That is, the service maintains its own state.

A platform-independent interface contract implies that a client from anywhere, on any OS, and in any language, can consume the service. Dynamic discovery hints that a discovery service (e.g., a directory service) is available. The directory service enables a look-up mechanism where consumers can go to find a service based on some criteria. For example, if I was looking for a credit-card authorization service, I might query the directory service to find a list of service providers that could authorize a credit card for a fee. Based on the fee, I would select a service (see Figure 1.1). The last property of a service is that the service be self-contained.

[[Image:SOA.gif|400x500px]]

=== Message ===

Service providers and consumers communicate via messages. Services expose an interface contract. This contract defines the behavior of the service and the messages they accept and return. Because the interface contract is platform- and language-independent, the technology used to define messages must also be agnostic to any specific platform/language. Therefore, messages are typically constructed using XML documents that conform to XML schema. XML provides all of the functionality, granularity, and scalability required by messages. That is, for consumers and providers to effectively communicate, they need a non-restrictive type of system to clearly define messages; XML provides this. Because consumers and providers communicate via messages, the structure and design of messages should not be taken lightly. Messages need to be implemented using a technology that supports the scalability requirements of services. Having to redesign messages will break the interface to providers, which can prove to be costly.

=== Dynamic Discovery ===

Dynamic discovery is an important piece of SOA. At a high level, SOA is composed of three core pieces: service providers, service consumers, and the directory service. The role of providers and consumers are apparent, but the role of the directory service needs some explanation. The directory service is an intermediary between providers and consumers. Providers register with the directory service and consumers query the directory service to find service providers. Most directory services typically organize services based on criteria and categorize them. Consumers can then use the directory services' search capabilities to find providers. Embedding a directory service within SOA accomplishes the following:

1. Scalability of services; you can add services incrementally.

2. Decouples consumers from providers.

3. Allows for hot updates of services.

4. Provides a look-up service for consumers.

5. Allows consumers to choose between providers at runtime rather than hard-coding a single provider.

=== Web Service ===

Although the concepts behind SOA were established long before web services came along, web services play a major role in a SOA. This is because web services are built on top of well-known and platform-independent protocols. These protocols include HTTP, XML, UDDI, WSDL, and SOAP. It is the combination of these protocols that make web services so attractive. Moreover, it is these protocols that fulfill the key requirements of a SOA. That is, a SOA requires that a service be dynamically discoverable and invokeable. This requirement is fulfilled by UDDI, WSDL, and SOAP. SOA requires that a service have a platform-independent interface contract. This requirement is fulfilled by XML. SOA stresses interoperability. This requirement is fulfilled by HTTP. This is why web services lie at the heart of SOA.

== Benefits of SOA ==

'''SOAs offer the following advantages over other approaches:'''

They offer business services across the platforms
They provide location independence
Services need not be at a particular system or particular network
Completely loosely coupled approach
Authentication and authorization support at every level
The search and connectivity to other services is dynamic

'''Short-term benefits of implementation:'''

Enhances reliability
Reduces hardware acquisition costs
Leverages existing development skills
Accelerates movement to standards-based server and application consolidation
Provides a data bridge between incompatible technologies

'''Long-term benefits of implementation:'''

Provides the ability to build composite applications
Creates a self-healing infrastructure that reduces management costs
Provides truly real-time decision-making applications
Enables the compilation of a unified taxonomy of information across an enterprise and its customer and partners

'''Benefits from the perspective of Business Value'''

Ability to more quickly meet customer demands
Lower costs associated with the acquisition and maintenance of technology
Management of business functionality closer to the business units
Leverages existing investments in technology
Reduces reliance on expensive custom development

== Areas in SOA Implementation where OO Concepts are used ==

As service oriented architecture gains popularity, it is starting to prove beneficial in places where OOP was inadequate. However, this does not mean an end to the OOP paradigm. Significant OOP principles are required by SOA architects to create interfaces to distributed applications.
The main areas where OO concepts come into picture are

''' 1. Interface Orientation '''
The interfaces should be at a higher level of abstraction from service implementation and should be able to provide well defined interfaces in an implementation-independent manner. There should be a comprehensive, uniform service specification with stable and well managed contracts.

''' 2. Interoperability '''
This is of prime concern to ensure seamless integration of applications in a heterogeneous environment. So they have to be interoperable, standard-based interfaces. Such technical standardization, coupled with business standardization will make SOA more effective.

''' 3. Autonomy and Modularity '''
An effective SOA architecture divides the existing architecture into autonomous sub systems. Care is to be taken that resources and functions are grouped together to ensure high cohesion and reduced runtime dependencies through a loosely coupled communication system.

== OO Concepts in SOA ==

=== Cohesion in SOA? ===

Steve Vinoski published a paper that talked about Cohesion and Coupling for services. In it he mentions 3 "good" types of cohesion that have been identified over the years:

Functional Cohesion: when a module does only one thing. They display low coupling and are highly reusable.
Sequential Cohesion: when a module carries out several tasks that must be ordered.
Communication Cohesion: when a module carries out multiple operations based on the same input, but which do not have any prescribed ordering requirements.

Then there are 4 forms of "bad" cohesion:

Procedural Cohesion: similar to Sequential Cohesion, except the data that each of the tasks works on is different. As Steve says: "Such cohesion often results from artificially grouping activities [to reduce coupling]."
Temporal Cohesion: when a module's tasks are related only by time. "Such modules cause maintenance problems if one task needs to be performed at a different time.|"
Logical Cohesion: where a module's activities are grouped because they appear to share common implementations.
Coincidental Cohesion: a module's tasks are related only by the fact they reside in the same module.
As Steve goes on to say:
Just as with coupling, cohesion still matters when applied to distributed objects and services. For example, if you grouped a bunch of methods in an object only because they had similar implementations, you would be guilty of creating a logically cohesive object.
The paper concludes with:
Given that transitions to “new” computing styles are often accompanied by explicit disapproval of the outgoing style, it’s no surprise that today’s focus on SOA has created a bit of a backlash against distributed objects. What’s unfortunate is that many of the measures of quality for distributed object systems apply equally well to distributed services and SOA, so it’s a shame that some feel compelled to ignore them just to be trendy. But perhaps it doesn’t matter, because we can just go back to the days before objects, dig up measures like coupling and cohesion, and apply them all over again — for the first time, of course.
Now this may have gone relatively unnoticed for the past few years, until Jim Webber's recent posting on Anemic Service Model. Skipping over the historical discussions about good software engineering practices, Jim says some very similar things to Steve's earlier work:
Some software is highly cohesive in design, but tightly coupled. This means though it may be logically laid out, it's tough to change because of tight interdependencies. That's pretty bad, and unfortunately also common for enterprise applications. Remember that software which really wowed you a few years ago but is much more of a pain to maintain than you'd like? That's because it's tightly coupled.

The other kind of bad software is loosely coupled but lacks cohesion. That means that there are few explicit interdependencies between modules, but none of the modules are necessarily authoritative about any particular aspect of the system. This in turn results in a scattergun approach to ongoing system evolution as even minor changes ripple through multiple components or systems. Or SOA as we have come to know it nowadays.

The entry then goes on to discuss how current SOA thinking really goes against this grain:
On the one hand we're inclined, and indeed encouraged by the SOA brigade, to think of this architecture as a good fit for purpose because it is very loosely coupled. Since every component or service is decoupled from every other component or service it should be possible to arrange and re-arrange them in a Lego-style in a myriad of useful ways. Building out "business services" from some more fundamental set of services is how the books tell us to do it. In fact we could even do that quite easily with point-and-client BPM tools, ruling out such overheads as developers and change management along the way. Right?

No. In fact absolutely wrong. [...] this is an architectural fantasy that has no place in real world enterprise systems. In fact a service that does not address a business problem has no right being in an SOA.
Now there are quite a few interesting comments on that posting. However, the real debate that this kicked off has been happening elsewhere, particularly with JJ's response:
Well someone who is trying single-handedly to topple SOA with a "Something Else Oriented Architecture" is Jim Webber -the MEST guy. [...] I found his post being completely erroneous. I may be missing something, but Jim is looking at the relationship between Cohesion and Loose Coupling. [...] For me cohesion sounds like a good engineering principle that looks a lot like "Dependency Structure Matrix". [...] The goal of loose coupling is precisely to mitigate cohesion as a good engineering principle. You can't be cohesive in a connected system. You can't be both cohesive and loosely coupled. Even in English, associating the two sounds really bad.
The goal of loose coupling is to make to pieces of code work together even though they may have been written at a different time, using different technologies, with a different security model, ...

SOA is about going away from cohesive systems to enable a wider range of reuse scenarios. Nested cohesive systems do provide a "nested" (library-style) reuse model: the upper layers can reuse the lower layers. Unfortunately, it forces us to create systems in a way that is incompatible with the way information systems should be architected. Cohesion is the problem, loose coupling is the solution. Jim, do you really think that people are trying to "keep stuff together in the same module"?

JJ posits that although cohesion is a well understood software engineering principle, it is not relevant to "modern" SOA:
I find it increasing irritating to see some people constantly aiming at "SOA" with ideas they cooked 5 years ago, when the only thing they are really aiming at is their own misunderstanding of SOA. [Jim is] showing pictures that are antiquated and certainly does not represent SOA in 2008.
And goes on to discuss Steve's original article as well:
... a cohesion requirement creates absolutely unnecessary constraints on the design of service interfaces and implementations that actually reduce the degree of reuse of a given service and its capacity to participate in different assemblies. Maybe it is time to become familiar with modern loose coupling concepts that include: bi-directional interfaces, assemblies, orchestration languages, extensible and semantically accessible data structures. Ancient programming techniques have been designed precisely because you did not have these concepts within your programming model.
The debate goes on though. Is cohesion fundamentally opposite to SOA? For instance, do we need to rewrite software engineering books to cover cohesion as it relates to SOA? Surely cohesion itself is not bad, but perhaps there are degrees of cohesion as there are of coupling, and one size does not fit all?

=== Design Patterns in SOA ===
A ‘service’ is the main design element of service oriented architecture. It encapsulates existing application logic and can be dynamically combined to form business processes. Services represent abstract software elements and/or interfaces which provide other applications with stable, reusable software functionality at a business-related level of granularity using widely applied standards. The OO design principles and design patterns which come in very handy when designing services are

''' 1. Service loose coupling '''
This design principle promotes the independent design and evolution of a service’s logic and implementation. But it still guarantees baseline interoperability with consumers that have come to rely on the service’s capabilities. There are numerous types of coupling involved in the design of a service, each of which can impact the content and granularity of its contract. Achieving the appropriate level of coupling requires that practical considerations be balanced against various service design preferences. Coupling should be such that runtime dependencies should be reduced to a minimum.

''' 2. Service Abstraction '''
Abstraction emphasizes the need to hide as much of the underlying details of a service as possible. This contributes in preserving the loosely coupled relationship. Service Abstraction also plays a significant role in the positioning and design of service compositions. Various forms of meta data come into the picture when assessing appropriate abstraction levels. The extent of abstraction applied can affect service contract granularity and can further influence the ultimate cost and effort of governing the service.

''' 3. Service Reusability '''
Reuse is a core part of typical service analysis and design processes, and also forms the basis for key service models. It emphasizes the positioning of services as enterprise resources with agnostic functional contexts. Numerous design considerations are raised to ensure that individual service capabilities are appropriately defined in relation to an agnostic service context, and to guarantee that they can facilitate the necessary reuse requirements.

''' 4. Service Autonomy '''
The principle of Service Autonomy supports the extent to which other design principles can be effectively realized in real world production environments by fostering design characteristics that increase a service’s reliability and behavioral predictability. This principle raises various issues that pertain to the design of service logic as well as the service’s actual implementation environment. Isolation levels and service normalization considerations are taken into account to achieve a suitable measure of autonomy, especially for reusable services that are frequently shared.

''' 5. Service Composability '''
As the level of sophistication and complexity in the design of a service grows, the ability to effectively compose services is a critical. Complex service compositions place demands on service design that need to be anticipated to avoid massive retro-fitting efforts. Services are expected to be capable of participating as effective composition members, regardless of whether they need to be immediately enlisted in a composition.

== Service Oriented Architecture in contrast with Enterprise Architecture ==

===Similarities===
SOA and EA domains share many similarities.

'''1 Both address similar architectural domains.'''

'''2 Both are intended to closely align IT with business.'''

'''3 Both use input based on business objectives.'''

'''4 Both require similar strategies and planning activities.'''

=== Differences ===

== Conclusion ==
Even though we have decades of experience in software development, we have yet to solve the mysteries of software complexity. As complexity grows, researchers find more innovative ways to answer the call. SOA, in combination with web services, is the latest answer. Application integration is one of the major issues companies face today; SOA can solve that. System availability, reliability, and scalability continue to bite companies today; SOA addresses these issues. Given today's requirements, SOA is the best scalable solution for application architecture.

CSC/ECE 517 Fall 2010/ch6 6j SO

2010-11-18T03:45:19Z

Solo2012: /* Service Oriented Architecture in contrast with Enterprise Architecture */

= Service-oriented architecture =

== Introduction ==

SOA (service-oriented architecture) has become a buzzword of late. The World Wide Web Consortium (W3C) refers to SOA as 'A set of components which can be invoked, and whose interface descriptions can be published and discovered'. Although the concepts behind SOA have been around for over a decade now, SOA has gained extreme popularity of late due to web services. Before we dive in and talk about what SOA is and what the essentials behind SOA are, it is a useful first step to look back at the evolution of SOA. To do that, we have to simply look at the challenges developers have faced over the past few decades and observe the solutions that have been proposed to solve their problems.

== The Problem ==

Early programmers realized that writing software was becoming more and more complex. They needed a better way to reuse some of the code that they were rewriting. When researchers took notice of this, they introduced the concept of modular design. With modular design principles, programmers could write subroutines and functions and reuse their code. This was great for a while. Later, developers started to see that they were cutting and pasting their modules into other applications and that this started to create a maintenance nightmare; when a bug was discovered in a function somewhere, they had to track down all of the applications that used the function and modify the code to reflect the fix. After the fix, the deployment nightmare began. Developers didn't like that; they needed a higher level of abstraction.

Researchers proposed classes and object-oriented software to solve this, and many more, problems. Again, as software complexity grew, developers started to see that developing and maintaining software was complex and they wanted a way to reuse and maintain functionality, not just code. Researchers offered yet another abstraction layer to handle this complexity -- component-based software. Component-based software is/was a good solution for reuse and maintenance, but it doesn't address all of the complexities developers are faced with today. Today, we face complex issues like distributed software, application integration, varying platforms, varying protocols, various devices, the Internet, etc. Today's software has to be equipped to answer the call for all of the above. In short, SOA (along with web services) provides a solution to all of the above. By adopting a SOA, you eliminate the headaches of protocol and platforms and your applications integrate seamlessly.

== Key Components of SOA ==

The first step in learning something new is to understand its vocabulary. In the context of SOA, we have the terms service, message, dynamic discovery, and web services. Each of these plays an essential role in SOA.

=== Service ===

A service in SOA is an exposed piece of functionality with three properties:

1. The interface contract to the service is platform-independent.

2. The service can be dynamically located and invoked.

3. The service is self-contained. That is, the service maintains its own state.

A platform-independent interface contract implies that a client from anywhere, on any OS, and in any language, can consume the service. Dynamic discovery hints that a discovery service (e.g., a directory service) is available. The directory service enables a look-up mechanism where consumers can go to find a service based on some criteria. For example, if I was looking for a credit-card authorization service, I might query the directory service to find a list of service providers that could authorize a credit card for a fee. Based on the fee, I would select a service (see Figure 1.1). The last property of a service is that the service be self-contained.

[[Image:SOA.gif|400x500px]]

=== Message ===

Service providers and consumers communicate via messages. Services expose an interface contract. This contract defines the behavior of the service and the messages they accept and return. Because the interface contract is platform- and language-independent, the technology used to define messages must also be agnostic to any specific platform/language. Therefore, messages are typically constructed using XML documents that conform to XML schema. XML provides all of the functionality, granularity, and scalability required by messages. That is, for consumers and providers to effectively communicate, they need a non-restrictive type of system to clearly define messages; XML provides this. Because consumers and providers communicate via messages, the structure and design of messages should not be taken lightly. Messages need to be implemented using a technology that supports the scalability requirements of services. Having to redesign messages will break the interface to providers, which can prove to be costly.

=== Dynamic Discovery ===

Dynamic discovery is an important piece of SOA. At a high level, SOA is composed of three core pieces: service providers, service consumers, and the directory service. The role of providers and consumers are apparent, but the role of the directory service needs some explanation. The directory service is an intermediary between providers and consumers. Providers register with the directory service and consumers query the directory service to find service providers. Most directory services typically organize services based on criteria and categorize them. Consumers can then use the directory services' search capabilities to find providers. Embedding a directory service within SOA accomplishes the following:

1. Scalability of services; you can add services incrementally.

2. Decouples consumers from providers.

3. Allows for hot updates of services.

4. Provides a look-up service for consumers.

5. Allows consumers to choose between providers at runtime rather than hard-coding a single provider.

=== Web Service ===

Although the concepts behind SOA were established long before web services came along, web services play a major role in a SOA. This is because web services are built on top of well-known and platform-independent protocols. These protocols include HTTP, XML, UDDI, WSDL, and SOAP. It is the combination of these protocols that make web services so attractive. Moreover, it is these protocols that fulfill the key requirements of a SOA. That is, a SOA requires that a service be dynamically discoverable and invokeable. This requirement is fulfilled by UDDI, WSDL, and SOAP. SOA requires that a service have a platform-independent interface contract. This requirement is fulfilled by XML. SOA stresses interoperability. This requirement is fulfilled by HTTP. This is why web services lie at the heart of SOA.

== Benefits of SOA ==

'''SOAs offer the following advantages over other approaches:'''

They offer business services across the platforms
They provide location independence
Services need not be at a particular system or particular network
Completely loosely coupled approach
Authentication and authorization support at every level
The search and connectivity to other services is dynamic

'''Short-term benefits of implementation:'''

Enhances reliability
Reduces hardware acquisition costs
Leverages existing development skills
Accelerates movement to standards-based server and application consolidation
Provides a data bridge between incompatible technologies

'''Long-term benefits of implementation:'''

Provides the ability to build composite applications
Creates a self-healing infrastructure that reduces management costs
Provides truly real-time decision-making applications
Enables the compilation of a unified taxonomy of information across an enterprise and its customer and partners

'''Benefits from the perspective of Business Value'''

Ability to more quickly meet customer demands
Lower costs associated with the acquisition and maintenance of technology
Management of business functionality closer to the business units
Leverages existing investments in technology
Reduces reliance on expensive custom development

== Areas in SOA Implementation where OO Concepts are used ==

As service oriented architecture gains popularity, it is starting to prove beneficial in places where OOP was inadequate. However, this does not mean an end to the OOP paradigm. Significant OOP principles are required by SOA architects to create interfaces to distributed applications.
The main areas where OO concepts come into picture are

''' 1. Interface Orientation '''
The interfaces should be at a higher level of abstraction from service implementation and should be able to provide well defined interfaces in an implementation-independent manner. There should be a comprehensive, uniform service specification with stable and well managed contracts.

''' 2. Interoperability '''
This is of prime concern to ensure seamless integration of applications in a heterogeneous environment. So they have to be interoperable, standard-based interfaces. Such technical standardization, coupled with business standardization will make SOA more effective.

''' 3. Autonomy and Modularity '''
An effective SOA architecture divides the existing architecture into autonomous sub systems. Care is to be taken that resources and functions are grouped together to ensure high cohesion and reduced runtime dependencies through a loosely coupled communication system.

== OO Concepts in SOA ==

=== Cohesion in SOA? ===

Steve Vinoski published a paper that talked about Cohesion and Coupling for services. In it he mentions 3 "good" types of cohesion that have been identified over the years:

Functional Cohesion: when a module does only one thing. They display low coupling and are highly reusable.
Sequential Cohesion: when a module carries out several tasks that must be ordered.
Communication Cohesion: when a module carries out multiple operations based on the same input, but which do not have any prescribed ordering requirements.

Then there are 4 forms of "bad" cohesion:

Procedural Cohesion: similar to Sequential Cohesion, except the data that each of the tasks works on is different. As Steve says: "Such cohesion often results from artificially grouping activities [to reduce coupling]."
Temporal Cohesion: when a module's tasks are related only by time. "Such modules cause maintenance problems if one task needs to be performed at a different time.|"
Logical Cohesion: where a module's activities are grouped because they appear to share common implementations.
Coincidental Cohesion: a module's tasks are related only by the fact they reside in the same module.
As Steve goes on to say:
Just as with coupling, cohesion still matters when applied to distributed objects and services. For example, if you grouped a bunch of methods in an object only because they had similar implementations, you would be guilty of creating a logically cohesive object.
The paper concludes with:
Given that transitions to “new” computing styles are often accompanied by explicit disapproval of the outgoing style, it’s no surprise that today’s focus on SOA has created a bit of a backlash against distributed objects. What’s unfortunate is that many of the measures of quality for distributed object systems apply equally well to distributed services and SOA, so it’s a shame that some feel compelled to ignore them just to be trendy. But perhaps it doesn’t matter, because we can just go back to the days before objects, dig up measures like coupling and cohesion, and apply them all over again — for the first time, of course.
Now this may have gone relatively unnoticed for the past few years, until Jim Webber's recent posting on Anemic Service Model. Skipping over the historical discussions about good software engineering practices, Jim says some very similar things to Steve's earlier work:
Some software is highly cohesive in design, but tightly coupled. This means though it may be logically laid out, it's tough to change because of tight interdependencies. That's pretty bad, and unfortunately also common for enterprise applications. Remember that software which really wowed you a few years ago but is much more of a pain to maintain than you'd like? That's because it's tightly coupled.

The other kind of bad software is loosely coupled but lacks cohesion. That means that there are few explicit interdependencies between modules, but none of the modules are necessarily authoritative about any particular aspect of the system. This in turn results in a scattergun approach to ongoing system evolution as even minor changes ripple through multiple components or systems. Or SOA as we have come to know it nowadays.

The entry then goes on to discuss how current SOA thinking really goes against this grain:
On the one hand we're inclined, and indeed encouraged by the SOA brigade, to think of this architecture as a good fit for purpose because it is very loosely coupled. Since every component or service is decoupled from every other component or service it should be possible to arrange and re-arrange them in a Lego-style in a myriad of useful ways. Building out "business services" from some more fundamental set of services is how the books tell us to do it. In fact we could even do that quite easily with point-and-client BPM tools, ruling out such overheads as developers and change management along the way. Right?

No. In fact absolutely wrong. [...] this is an architectural fantasy that has no place in real world enterprise systems. In fact a service that does not address a business problem has no right being in an SOA.
Now there are quite a few interesting comments on that posting. However, the real debate that this kicked off has been happening elsewhere, particularly with JJ's response:
Well someone who is trying single-handedly to topple SOA with a "Something Else Oriented Architecture" is Jim Webber -the MEST guy. [...] I found his post being completely erroneous. I may be missing something, but Jim is looking at the relationship between Cohesion and Loose Coupling. [...] For me cohesion sounds like a good engineering principle that looks a lot like "Dependency Structure Matrix". [...] The goal of loose coupling is precisely to mitigate cohesion as a good engineering principle. You can't be cohesive in a connected system. You can't be both cohesive and loosely coupled. Even in English, associating the two sounds really bad.
The goal of loose coupling is to make to pieces of code work together even though they may have been written at a different time, using different technologies, with a different security model, ...

SOA is about going away from cohesive systems to enable a wider range of reuse scenarios. Nested cohesive systems do provide a "nested" (library-style) reuse model: the upper layers can reuse the lower layers. Unfortunately, it forces us to create systems in a way that is incompatible with the way information systems should be architected. Cohesion is the problem, loose coupling is the solution. Jim, do you really think that people are trying to "keep stuff together in the same module"?

JJ posits that although cohesion is a well understood software engineering principle, it is not relevant to "modern" SOA:
I find it increasing irritating to see some people constantly aiming at "SOA" with ideas they cooked 5 years ago, when the only thing they are really aiming at is their own misunderstanding of SOA. [Jim is] showing pictures that are antiquated and certainly does not represent SOA in 2008.
And goes on to discuss Steve's original article as well:
... a cohesion requirement creates absolutely unnecessary constraints on the design of service interfaces and implementations that actually reduce the degree of reuse of a given service and its capacity to participate in different assemblies. Maybe it is time to become familiar with modern loose coupling concepts that include: bi-directional interfaces, assemblies, orchestration languages, extensible and semantically accessible data structures. Ancient programming techniques have been designed precisely because you did not have these concepts within your programming model.
The debate goes on though. Is cohesion fundamentally opposite to SOA? For instance, do we need to rewrite software engineering books to cover cohesion as it relates to SOA? Surely cohesion itself is not bad, but perhaps there are degrees of cohesion as there are of coupling, and one size does not fit all?

=== Design Patterns in SOA ===
A ‘service’ is the main design element of service oriented architecture. It encapsulates existing application logic and can be dynamically combined to form business processes. Services represent abstract software elements and/or interfaces which provide other applications with stable, reusable software functionality at a business-related level of granularity using widely applied standards. The OO design principles and design patterns which come in very handy when designing services are

''' 1. Service loose coupling '''
This design principle promotes the independent design and evolution of a service’s logic and implementation. But it still guarantees baseline interoperability with consumers that have come to rely on the service’s capabilities. There are numerous types of coupling involved in the design of a service, each of which can impact the content and granularity of its contract. Achieving the appropriate level of coupling requires that practical considerations be balanced against various service design preferences. Coupling should be such that runtime dependencies should be reduced to a minimum.

''' 2. Service Abstraction '''
Abstraction emphasizes the need to hide as much of the underlying details of a service as possible. This contributes in preserving the loosely coupled relationship. Service Abstraction also plays a significant role in the positioning and design of service compositions. Various forms of meta data come into the picture when assessing appropriate abstraction levels. The extent of abstraction applied can affect service contract granularity and can further influence the ultimate cost and effort of governing the service.

''' 3. Service Reusability '''
Reuse is a core part of typical service analysis and design processes, and also forms the basis for key service models. It emphasizes the positioning of services as enterprise resources with agnostic functional contexts. Numerous design considerations are raised to ensure that individual service capabilities are appropriately defined in relation to an agnostic service context, and to guarantee that they can facilitate the necessary reuse requirements.

''' 4. Service Autonomy '''
The principle of Service Autonomy supports the extent to which other design principles can be effectively realized in real world production environments by fostering design characteristics that increase a service’s reliability and behavioral predictability. This principle raises various issues that pertain to the design of service logic as well as the service’s actual implementation environment. Isolation levels and service normalization considerations are taken into account to achieve a suitable measure of autonomy, especially for reusable services that are frequently shared.

''' 5. Service Composability '''
As the level of sophistication and complexity in the design of a service grows, the ability to effectively compose services is a critical. Complex service compositions place demands on service design that need to be anticipated to avoid massive retro-fitting efforts. Services are expected to be capable of participating as effective composition members, regardless of whether they need to be immediately enlisted in a composition.

== Service Oriented Architecture in contrast with Enterprise Architecture ==

===Similarities===
SOA and EA domains share many similarities.

'''1 Both address similar architectural domains.'''
'''2 Both are intended to closely align IT with business.'''
'''3 Both use input based on business objectives.'''
'''4 Both require similar strategies and planning activities.'''

=== Differences ===

== Conclusion ==
Even though we have decades of experience in software development, we have yet to solve the mysteries of software complexity. As complexity grows, researchers find more innovative ways to answer the call. SOA, in combination with web services, is the latest answer. Application integration is one of the major issues companies face today; SOA can solve that. System availability, reliability, and scalability continue to bite companies today; SOA addresses these issues. Given today's requirements, SOA is the best scalable solution for application architecture.

CSC/ECE 517 Fall 2010/ch6 6j SO

2010-11-18T03:43:50Z

Solo2012:

= Service-oriented architecture =

== Introduction ==

SOA (service-oriented architecture) has become a buzzword of late. The World Wide Web Consortium (W3C) refers to SOA as 'A set of components which can be invoked, and whose interface descriptions can be published and discovered'. Although the concepts behind SOA have been around for over a decade now, SOA has gained extreme popularity of late due to web services. Before we dive in and talk about what SOA is and what the essentials behind SOA are, it is a useful first step to look back at the evolution of SOA. To do that, we have to simply look at the challenges developers have faced over the past few decades and observe the solutions that have been proposed to solve their problems.

== The Problem ==

Early programmers realized that writing software was becoming more and more complex. They needed a better way to reuse some of the code that they were rewriting. When researchers took notice of this, they introduced the concept of modular design. With modular design principles, programmers could write subroutines and functions and reuse their code. This was great for a while. Later, developers started to see that they were cutting and pasting their modules into other applications and that this started to create a maintenance nightmare; when a bug was discovered in a function somewhere, they had to track down all of the applications that used the function and modify the code to reflect the fix. After the fix, the deployment nightmare began. Developers didn't like that; they needed a higher level of abstraction.

Researchers proposed classes and object-oriented software to solve this, and many more, problems. Again, as software complexity grew, developers started to see that developing and maintaining software was complex and they wanted a way to reuse and maintain functionality, not just code. Researchers offered yet another abstraction layer to handle this complexity -- component-based software. Component-based software is/was a good solution for reuse and maintenance, but it doesn't address all of the complexities developers are faced with today. Today, we face complex issues like distributed software, application integration, varying platforms, varying protocols, various devices, the Internet, etc. Today's software has to be equipped to answer the call for all of the above. In short, SOA (along with web services) provides a solution to all of the above. By adopting a SOA, you eliminate the headaches of protocol and platforms and your applications integrate seamlessly.

== Key Components of SOA ==

The first step in learning something new is to understand its vocabulary. In the context of SOA, we have the terms service, message, dynamic discovery, and web services. Each of these plays an essential role in SOA.

=== Service ===

A service in SOA is an exposed piece of functionality with three properties:

1. The interface contract to the service is platform-independent.

2. The service can be dynamically located and invoked.

3. The service is self-contained. That is, the service maintains its own state.

A platform-independent interface contract implies that a client from anywhere, on any OS, and in any language, can consume the service. Dynamic discovery hints that a discovery service (e.g., a directory service) is available. The directory service enables a look-up mechanism where consumers can go to find a service based on some criteria. For example, if I was looking for a credit-card authorization service, I might query the directory service to find a list of service providers that could authorize a credit card for a fee. Based on the fee, I would select a service (see Figure 1.1). The last property of a service is that the service be self-contained.

[[Image:SOA.gif|400x500px]]

=== Message ===

Service providers and consumers communicate via messages. Services expose an interface contract. This contract defines the behavior of the service and the messages they accept and return. Because the interface contract is platform- and language-independent, the technology used to define messages must also be agnostic to any specific platform/language. Therefore, messages are typically constructed using XML documents that conform to XML schema. XML provides all of the functionality, granularity, and scalability required by messages. That is, for consumers and providers to effectively communicate, they need a non-restrictive type of system to clearly define messages; XML provides this. Because consumers and providers communicate via messages, the structure and design of messages should not be taken lightly. Messages need to be implemented using a technology that supports the scalability requirements of services. Having to redesign messages will break the interface to providers, which can prove to be costly.

=== Dynamic Discovery ===

Dynamic discovery is an important piece of SOA. At a high level, SOA is composed of three core pieces: service providers, service consumers, and the directory service. The role of providers and consumers are apparent, but the role of the directory service needs some explanation. The directory service is an intermediary between providers and consumers. Providers register with the directory service and consumers query the directory service to find service providers. Most directory services typically organize services based on criteria and categorize them. Consumers can then use the directory services' search capabilities to find providers. Embedding a directory service within SOA accomplishes the following:

1. Scalability of services; you can add services incrementally.

2. Decouples consumers from providers.

3. Allows for hot updates of services.

4. Provides a look-up service for consumers.

5. Allows consumers to choose between providers at runtime rather than hard-coding a single provider.

=== Web Service ===

Although the concepts behind SOA were established long before web services came along, web services play a major role in a SOA. This is because web services are built on top of well-known and platform-independent protocols. These protocols include HTTP, XML, UDDI, WSDL, and SOAP. It is the combination of these protocols that make web services so attractive. Moreover, it is these protocols that fulfill the key requirements of a SOA. That is, a SOA requires that a service be dynamically discoverable and invokeable. This requirement is fulfilled by UDDI, WSDL, and SOAP. SOA requires that a service have a platform-independent interface contract. This requirement is fulfilled by XML. SOA stresses interoperability. This requirement is fulfilled by HTTP. This is why web services lie at the heart of SOA.

== Benefits of SOA ==

'''SOAs offer the following advantages over other approaches:'''

They offer business services across the platforms
They provide location independence
Services need not be at a particular system or particular network
Completely loosely coupled approach
Authentication and authorization support at every level
The search and connectivity to other services is dynamic

'''Short-term benefits of implementation:'''

Enhances reliability
Reduces hardware acquisition costs
Leverages existing development skills
Accelerates movement to standards-based server and application consolidation
Provides a data bridge between incompatible technologies

'''Long-term benefits of implementation:'''

Provides the ability to build composite applications
Creates a self-healing infrastructure that reduces management costs
Provides truly real-time decision-making applications
Enables the compilation of a unified taxonomy of information across an enterprise and its customer and partners

'''Benefits from the perspective of Business Value'''

Ability to more quickly meet customer demands
Lower costs associated with the acquisition and maintenance of technology
Management of business functionality closer to the business units
Leverages existing investments in technology
Reduces reliance on expensive custom development

== Areas in SOA Implementation where OO Concepts are used ==

As service oriented architecture gains popularity, it is starting to prove beneficial in places where OOP was inadequate. However, this does not mean an end to the OOP paradigm. Significant OOP principles are required by SOA architects to create interfaces to distributed applications.
The main areas where OO concepts come into picture are

''' 1. Interface Orientation '''
The interfaces should be at a higher level of abstraction from service implementation and should be able to provide well defined interfaces in an implementation-independent manner. There should be a comprehensive, uniform service specification with stable and well managed contracts.

''' 2. Interoperability '''
This is of prime concern to ensure seamless integration of applications in a heterogeneous environment. So they have to be interoperable, standard-based interfaces. Such technical standardization, coupled with business standardization will make SOA more effective.

''' 3. Autonomy and Modularity '''
An effective SOA architecture divides the existing architecture into autonomous sub systems. Care is to be taken that resources and functions are grouped together to ensure high cohesion and reduced runtime dependencies through a loosely coupled communication system.

== OO Concepts in SOA ==

=== Cohesion in SOA? ===

Steve Vinoski published a paper that talked about Cohesion and Coupling for services. In it he mentions 3 "good" types of cohesion that have been identified over the years:

Functional Cohesion: when a module does only one thing. They display low coupling and are highly reusable.
Sequential Cohesion: when a module carries out several tasks that must be ordered.
Communication Cohesion: when a module carries out multiple operations based on the same input, but which do not have any prescribed ordering requirements.

Then there are 4 forms of "bad" cohesion:

Procedural Cohesion: similar to Sequential Cohesion, except the data that each of the tasks works on is different. As Steve says: "Such cohesion often results from artificially grouping activities [to reduce coupling]."
Temporal Cohesion: when a module's tasks are related only by time. "Such modules cause maintenance problems if one task needs to be performed at a different time.|"
Logical Cohesion: where a module's activities are grouped because they appear to share common implementations.
Coincidental Cohesion: a module's tasks are related only by the fact they reside in the same module.
As Steve goes on to say:
Just as with coupling, cohesion still matters when applied to distributed objects and services. For example, if you grouped a bunch of methods in an object only because they had similar implementations, you would be guilty of creating a logically cohesive object.
The paper concludes with:
Given that transitions to “new” computing styles are often accompanied by explicit disapproval of the outgoing style, it’s no surprise that today’s focus on SOA has created a bit of a backlash against distributed objects. What’s unfortunate is that many of the measures of quality for distributed object systems apply equally well to distributed services and SOA, so it’s a shame that some feel compelled to ignore them just to be trendy. But perhaps it doesn’t matter, because we can just go back to the days before objects, dig up measures like coupling and cohesion, and apply them all over again — for the first time, of course.
Now this may have gone relatively unnoticed for the past few years, until Jim Webber's recent posting on Anemic Service Model. Skipping over the historical discussions about good software engineering practices, Jim says some very similar things to Steve's earlier work:
Some software is highly cohesive in design, but tightly coupled. This means though it may be logically laid out, it's tough to change because of tight interdependencies. That's pretty bad, and unfortunately also common for enterprise applications. Remember that software which really wowed you a few years ago but is much more of a pain to maintain than you'd like? That's because it's tightly coupled.

The other kind of bad software is loosely coupled but lacks cohesion. That means that there are few explicit interdependencies between modules, but none of the modules are necessarily authoritative about any particular aspect of the system. This in turn results in a scattergun approach to ongoing system evolution as even minor changes ripple through multiple components or systems. Or SOA as we have come to know it nowadays.

The entry then goes on to discuss how current SOA thinking really goes against this grain:
On the one hand we're inclined, and indeed encouraged by the SOA brigade, to think of this architecture as a good fit for purpose because it is very loosely coupled. Since every component or service is decoupled from every other component or service it should be possible to arrange and re-arrange them in a Lego-style in a myriad of useful ways. Building out "business services" from some more fundamental set of services is how the books tell us to do it. In fact we could even do that quite easily with point-and-client BPM tools, ruling out such overheads as developers and change management along the way. Right?

No. In fact absolutely wrong. [...] this is an architectural fantasy that has no place in real world enterprise systems. In fact a service that does not address a business problem has no right being in an SOA.
Now there are quite a few interesting comments on that posting. However, the real debate that this kicked off has been happening elsewhere, particularly with JJ's response:
Well someone who is trying single-handedly to topple SOA with a "Something Else Oriented Architecture" is Jim Webber -the MEST guy. [...] I found his post being completely erroneous. I may be missing something, but Jim is looking at the relationship between Cohesion and Loose Coupling. [...] For me cohesion sounds like a good engineering principle that looks a lot like "Dependency Structure Matrix". [...] The goal of loose coupling is precisely to mitigate cohesion as a good engineering principle. You can't be cohesive in a connected system. You can't be both cohesive and loosely coupled. Even in English, associating the two sounds really bad.
The goal of loose coupling is to make to pieces of code work together even though they may have been written at a different time, using different technologies, with a different security model, ...

SOA is about going away from cohesive systems to enable a wider range of reuse scenarios. Nested cohesive systems do provide a "nested" (library-style) reuse model: the upper layers can reuse the lower layers. Unfortunately, it forces us to create systems in a way that is incompatible with the way information systems should be architected. Cohesion is the problem, loose coupling is the solution. Jim, do you really think that people are trying to "keep stuff together in the same module"?

JJ posits that although cohesion is a well understood software engineering principle, it is not relevant to "modern" SOA:
I find it increasing irritating to see some people constantly aiming at "SOA" with ideas they cooked 5 years ago, when the only thing they are really aiming at is their own misunderstanding of SOA. [Jim is] showing pictures that are antiquated and certainly does not represent SOA in 2008.
And goes on to discuss Steve's original article as well:
... a cohesion requirement creates absolutely unnecessary constraints on the design of service interfaces and implementations that actually reduce the degree of reuse of a given service and its capacity to participate in different assemblies. Maybe it is time to become familiar with modern loose coupling concepts that include: bi-directional interfaces, assemblies, orchestration languages, extensible and semantically accessible data structures. Ancient programming techniques have been designed precisely because you did not have these concepts within your programming model.
The debate goes on though. Is cohesion fundamentally opposite to SOA? For instance, do we need to rewrite software engineering books to cover cohesion as it relates to SOA? Surely cohesion itself is not bad, but perhaps there are degrees of cohesion as there are of coupling, and one size does not fit all?

=== Design Patterns in SOA ===
A ‘service’ is the main design element of service oriented architecture. It encapsulates existing application logic and can be dynamically combined to form business processes. Services represent abstract software elements and/or interfaces which provide other applications with stable, reusable software functionality at a business-related level of granularity using widely applied standards. The OO design principles and design patterns which come in very handy when designing services are

''' 1. Service loose coupling '''
This design principle promotes the independent design and evolution of a service’s logic and implementation. But it still guarantees baseline interoperability with consumers that have come to rely on the service’s capabilities. There are numerous types of coupling involved in the design of a service, each of which can impact the content and granularity of its contract. Achieving the appropriate level of coupling requires that practical considerations be balanced against various service design preferences. Coupling should be such that runtime dependencies should be reduced to a minimum.

''' 2. Service Abstraction '''
Abstraction emphasizes the need to hide as much of the underlying details of a service as possible. This contributes in preserving the loosely coupled relationship. Service Abstraction also plays a significant role in the positioning and design of service compositions. Various forms of meta data come into the picture when assessing appropriate abstraction levels. The extent of abstraction applied can affect service contract granularity and can further influence the ultimate cost and effort of governing the service.

''' 3. Service Reusability '''
Reuse is a core part of typical service analysis and design processes, and also forms the basis for key service models. It emphasizes the positioning of services as enterprise resources with agnostic functional contexts. Numerous design considerations are raised to ensure that individual service capabilities are appropriately defined in relation to an agnostic service context, and to guarantee that they can facilitate the necessary reuse requirements.

''' 4. Service Autonomy '''
The principle of Service Autonomy supports the extent to which other design principles can be effectively realized in real world production environments by fostering design characteristics that increase a service’s reliability and behavioral predictability. This principle raises various issues that pertain to the design of service logic as well as the service’s actual implementation environment. Isolation levels and service normalization considerations are taken into account to achieve a suitable measure of autonomy, especially for reusable services that are frequently shared.

''' 5. Service Composability '''
As the level of sophistication and complexity in the design of a service grows, the ability to effectively compose services is a critical. Complex service compositions place demands on service design that need to be anticipated to avoid massive retro-fitting efforts. Services are expected to be capable of participating as effective composition members, regardless of whether they need to be immediately enlisted in a composition.

== Service Oriented Architecture in contrast with Enterprise Architecture ==

===Similarities===
SOA and EA domains share many similarities.

'''• Both address similar architectural domains.'''
'''• Both are intended to closely align IT with business.'''
'''• Both use input based on business objectives.'''
'''• Both require similar strategies and planning activities.'''

=== Differences ===

== Conclusion ==
Even though we have decades of experience in software development, we have yet to solve the mysteries of software complexity. As complexity grows, researchers find more innovative ways to answer the call. SOA, in combination with web services, is the latest answer. Application integration is one of the major issues companies face today; SOA can solve that. System availability, reliability, and scalability continue to bite companies today; SOA addresses these issues. Given today's requirements, SOA is the best scalable solution for application architecture.

User:Bluehat

2010-09-08T15:17:47Z

Solo2012: /* Reference */

==Introduction==

The onset of the object oriented paradigm in the software industry brought about a big change in the basic approach to system design and the software development life cycle.The major task in the development of any application using the object oriented paradigm is to identify ‘classes’, and how these classes interact and collaborate with each other in the system scope.

Whenever a system is designed with classes, each class has a specific role to play in the system.It has certain responsibilities and each class collaborates with other classes to provide the complete system functionality. In such a scenario, identifying classes becomes the key to a good system design.Although it seems to be a simple,intuitive process,identifying classes can be quite complex when it comes to large scale systems.

One such technique for identification of classes that make up the system and its collaborations is the ‘CRC Card’ technique. The concept of CRC cards was first put forth by Kent Beck and Ward Cunningham and it became very popular as it is easy to use and it supports development of any kind of object oriented development regardless of its scale,the method used, the technology or the language used for development

==Definition==
Class Responsibility Collaboration (CRC) cards is an object-oriented design method that uses ordinary 3x5 index cards card made for each class containing responsibilities (knowledge and services) and collaborators (interactions with other classes). The cards provide an informal, intuitive way for group members to work on object design together.
A typical CRC card layout is shown below.
[[Image:Crccard2.jpg|frame|center|CRC CARD Template]]

Example: Consider a Student class where a student can enroll for a seminar. In this case ‘Student’ will be one class and ‘Seminar’ can be another class that collaborates with the Student class.

[[Image:CrcStudent.jpg|frame|center|Student CRC Card ]]

To know more about CRC cards please refer to http://www.hsanchez.net/repository/hsanchez-PLCRC-plop04.pdf

==Principle and Process==

===CRC Principle===

A CRC model includes a collection of cards and each card is divided into three sections.
*Class Name:
**Appears on the top of the CRC card
**Class denotes a set of similar objects that are being modeled in the system

*Responsibilities:
**Appears on the left hand side of the CRC card
**It is a list of the responsibilities of the class i.e. things a class can do with its knowledge

*Collaborators:
**Appear on the right hand side of the CRC card
**They are other classes that the class works with to get information or perform a certain function

===CRC Process===

CRC modeling process includes the users, analysts and developers bringing together the entire development team to form a common understanding of an OO development project.For e.g consider a software application to implement a game of blackjack. To implement the CRC technique to design this software, following steps are taken:

*Explanation of the CRC Technique
**The facilitator explains the purpose of the CRC modeling session
**It can include explanation of CRC Cards and creation of sample CRC Cards

*Brainstorming
**A brainstorming session at the very beginning brings in new ideas, new perspectives to the problem being solved.
**Every team member can contribute with innovative ideas
**A list of candidate classes can be drawn up from this activity

For e.g considering the above example, we can identify candidate classes by listing down the nouns relating to the game of blackjack. Say, game, blackjack, dealer, players, card, deck, hand, bet, king, queen, jack, ace, suit, winner, game.

*Selecting a scenario and Core classes
**The scenario chosen at the beginning of the session should be simple, clear and well documented
**Related scenarios should be identified and dealt with separately
**Identification of critical classes from the candidate class list is also very important
**This helps to eliminate irrelevant classes and review remaining classes
**This also helps clarify the system scope

For e.g we can apply the elimination process to the candidate class list. We can eliminate blackjack as it is the name of the system. ‘House’ can be eliminated as it is another name for the dealer. Also, instead of making ace, king, queen and jack as separate classes, we can represent them as attributes of individual classes.

*Create initial CRC cards
From the information gathered in the step above, CRC cards are written

[[Image:Deck1.jpg |frame|center|Deck CRC Card]]

[[Image:Dealer.jpg |frame|center|Dealer CRC Card]]

[[Image:Player.jpg |frame|center|Player CRC Card]]

*Creating a CRC Model
**After the CRC cards are written, they are placed appropriately, with collaborating classes closer to each other.
**Accordingly, place each card in position till the entire picture of the system is finalized.
**This process may have to be done in several iterations to get a refined view of the system to be modeled.

For more information on using CRC Cards please refer to http://alistair.cockburn.us/Using+CRC+cards

==CRC Team==

*Domain Experts:
**Core team that writes the cards
**Have good business domain knowledge for which the system is being designed
**Usually are 3-5 people

*Object Oriented Design Analyst:
**Analysts and developers those are familiar with object oriented design methodologies
**Usually are 1-2 people

*Facilitator:
**Most important member who conducts the CRC modeling session
**Acts as an intermediary when there is difference of opinion regarding class responsibilities and paths of collaboration
**Usually a single person

*Scribe:
**Responsible for documenting any business logic that evolves by way of discussions during the CRC modeling process.
**This documentation can be added to the requirements and business documents which can be used by design analysts at a later stage
**Usually are 1-2 people

==Case study==

To understand the working of CRC card modeling better, here is an example of an ATM system designed using CRC cards. Here, the software system under consideration has to control an automated teller machine. The ATM has a magnetic stripe reader for reading an ATM card, a customer console (keyboard and display) for interaction with the customer, a slot for depositing envelopes, a dispenser for cash (in multiples of $20), a printer for printing customer receipts, and a key-operated switch to allow an operator to start or stop the machine. Also, the ATM will communicate with the bank's computer over an appropriate communication link.

To perform a transaction, a customer will be required to insert an ATM card and enter a personal identification number (PIN) - both of which will be sent to the bank for validation. The customer will then be able to perform one or more transactions. The card will be retained in the machine until the customer indicates that there are no further transactions, at which point it will be returned. For more on the case study.

http://www.math-cs.gordon.edu/courses/cps211/ATMExample/CRCCards.html

==Metrics for CRC Analysis==

CRC analysis metrics can help evaluate the level of ease in designing and coding with CRC cards. These metrics also contribute to other project planning factors to give overall sense of project development.These metrics can be calculated easily and quickly without the need of special tools. Three metrics are broadly identified as: maximum depth of inheritance, the number of responsibilities assigned to each class and the number of collaborators for a class. With the example below an attempt has been made to explain these metrics.In the diagram, black line indicates inheritance while blue line indicates collaboration.

[[Image:Class_hierarchy1.png|frame|center|CRC metrics example]]

===Maximum depth of inheritance===

This metric gives an idea of the class hierarchy. It is the count of number of subclasses in the hierarchy.From the diagram,it can be seen that Part Time student is a subclass of Distance Education which in turn is a subclass of student.Thus,maximum depth of inheritance in this case is two with reference to class Student. Each subclass shares the overall functions defined in class Student. For short hierarchies, this is a positive benefit of OO. If number of subclasses become too long, it becomes difficult to trace the flow of functions, resulting in overly complex systems. This makes testing, reviewing and reusing difficult.

===Number of collaborators===

This is the count of all the supporting classes to help a class.In the diagram,there are four collaborators for class Student:Teacher,Library,Computer Labs and Gymnasium.Confusion between collaborators and subclasses may result in creation many collaborators.This will affect the encapsulation of the design.Typical value for this metric is eight.If this value is large,design may be reviewed to see if inheritance is implemented correctly.

===Number of responsibilities===
This is the count of clearly defined set of duties to each class.For example class Student may have functions like Attending Lectures,
Maintaining a certain GPA,Taking the required courses. In this case number of responsibilities is three.Responsibilities should be distributed amongst classes to cover the whole system. This would avoid an imbalance in design. We need to refine the overly complex class into a series of simpler objects. This will make the system easier to understand, implement and reuse. For most commercial transaction oriented systems, values approximately between eight and eighteen are common.

==Advantages==
* CRC cards create a first-cut analysis for complex systems, and let analysts and users examine the operation of discrete subsystems.
* CRC cards are invaluable input into more formal methods. Agile development methods often use CRC cards. They are popular as a front end to UML
* CRC cards are a great way to build teamwork and common understanding.
* Part of the CRC card attraction is their simplicity. Developers can use them with little formal training and just paper and pencil for tools

==Software for CRC card==

It is difficult to maintain, change, share paper based cards for large projects. Software for CRC cards offer many advantages in such scenarios such as

*Easy Revision: As CRC cards are part of development process, constant changes are made by developers to edit the information .Change to one card might require changes to other cards. It becomes difficult to handle such interdependent changes for various fields such as attribute, responsibility, collaboration on paper based system. Software will reflect one change to every corresponding reference in the design. This saves a lot of time and also avoids the manual errors that may be evident on paper based system.

*Easy sharing: Paper based systems make sharing difficult by necessitating team members to be physically present at one location. Using software, team members can work from different locations.

*Better representation: It is possible to group cards from different perspective such as hierarchy, attributes, parent. This helps better understanding and thinking. Some software also aid graphical display of data.

*Inputs to methodologies: Software for CRC cards can provide the input files for UML class diagram generation software saving lot of time in the development cycle.

*Making additions to existing code: Many projects make addition to existing code or reuse already developed code in their project. Software can produce CRC cards with existing source code as an input. This would help the team to understand the code in efficient manner and less time.

However,it comes with a cost.Based on required features and cost,team may select from various commercially available software products.Below are few links:

*quickCRC:http://www.excelsoftware.com/
*CRC card support is part of Visual Paradigm for UML: http://www.visual-paradigm.com/

==CRC cards Limitations and formal object modeling methodologies(UML)==

CRC cards are used to form initial class definitions but alone are not sufficient to be directly coded into software for large systems.It is difficult to keep track of cards as the systems grows and work on subsystems simultaneously and independently.CRC cards lack the notational power to document all the components of a system and cannot provide implementation specifications such as transition states of objects during its life cycle,interface design,data structures,performance and resource utilization. To bridge this gap,more formal object modeling methodology such as UML is used.UML captures the bigger picture.It provides detailed mapping of use cases(operations),object state transitions,inter-process communication functionality,algorithm design.UML is very effective in incremental model of SDLC where lot of details need to captured for precise addition.Information about requirements is represented in detail and whole picture of the system and users is visible.CRC cards are used as effective inputs to UML.CRC card techniques such as brainstorming and role play help enhance functional understanding which helps in preparing better UML use cases.CRC cards given the content for class diagrams,inheritance diagrams,class specifications and object specifications for UML.CRC cards can keep track of attributes that can aid listing them as a part of class specification in UML.Most CRC card software have the facility to export CRC analysis file that can be directly used as an input for UML.Following case study develops UML with the help of CRC cards:

http://www.math.gordon.edu/courses/cs211/ATMExample/

==Summary==
CRC cards are very useful to form the base of object oriented methodology.Techniques such as brain storming and role play enhance the understanding of requirements.CRC automation makes card handling and sharing quick and efficient.For large projects more formal technology such as UML is required but CRC cards can provide a very good starting point.

==Reference==
*[1]Introduction to CRC Cards: http://www.softstar-inc.com/Download/Intro%20to%20CRC.pdf
*[2]CRC Cards for ATM : http://www.math-cs.gordon.edu/courses/cps211/ATMExample/CRCCards.html
*[3]UML methodology for ATM :http://www.math.gordon.edu/courses/cs211/ATMExample/
*[4]CRC software:
**quickCRC:http://www.excelsoftware.com/
**Visual Paradigm: http://www.visual-paradigm.com/
*[5]Bellin, D and Simone, S.S ‘The CRC Card Book’, Addison Wesely, 1997

User:Bluehat

2010-09-08T15:17:10Z

Solo2012: /* Reference */

==Introduction==

The onset of the object oriented paradigm in the software industry brought about a big change in the basic approach to system design and the software development life cycle.The major task in the development of any application using the object oriented paradigm is to identify ‘classes’, and how these classes interact and collaborate with each other in the system scope.

Whenever a system is designed with classes, each class has a specific role to play in the system.It has certain responsibilities and each class collaborates with other classes to provide the complete system functionality. In such a scenario, identifying classes becomes the key to a good system design.Although it seems to be a simple,intuitive process,identifying classes can be quite complex when it comes to large scale systems.

One such technique for identification of classes that make up the system and its collaborations is the ‘CRC Card’ technique. The concept of CRC cards was first put forth by Kent Beck and Ward Cunningham and it became very popular as it is easy to use and it supports development of any kind of object oriented development regardless of its scale,the method used, the technology or the language used for development

==Definition==
Class Responsibility Collaboration (CRC) cards is an object-oriented design method that uses ordinary 3x5 index cards card made for each class containing responsibilities (knowledge and services) and collaborators (interactions with other classes). The cards provide an informal, intuitive way for group members to work on object design together.
A typical CRC card layout is shown below.
[[Image:Crccard2.jpg|frame|center|CRC CARD Template]]

Example: Consider a Student class where a student can enroll for a seminar. In this case ‘Student’ will be one class and ‘Seminar’ can be another class that collaborates with the Student class.

[[Image:CrcStudent.jpg|frame|center|Student CRC Card ]]

To know more about CRC cards please refer to http://www.hsanchez.net/repository/hsanchez-PLCRC-plop04.pdf

==Principle and Process==

===CRC Principle===

A CRC model includes a collection of cards and each card is divided into three sections.
*Class Name:
**Appears on the top of the CRC card
**Class denotes a set of similar objects that are being modeled in the system

*Responsibilities:
**Appears on the left hand side of the CRC card
**It is a list of the responsibilities of the class i.e. things a class can do with its knowledge

*Collaborators:
**Appear on the right hand side of the CRC card
**They are other classes that the class works with to get information or perform a certain function

===CRC Process===

CRC modeling process includes the users, analysts and developers bringing together the entire development team to form a common understanding of an OO development project.For e.g consider a software application to implement a game of blackjack. To implement the CRC technique to design this software, following steps are taken:

*Explanation of the CRC Technique
**The facilitator explains the purpose of the CRC modeling session
**It can include explanation of CRC Cards and creation of sample CRC Cards

*Brainstorming
**A brainstorming session at the very beginning brings in new ideas, new perspectives to the problem being solved.
**Every team member can contribute with innovative ideas
**A list of candidate classes can be drawn up from this activity

For e.g considering the above example, we can identify candidate classes by listing down the nouns relating to the game of blackjack. Say, game, blackjack, dealer, players, card, deck, hand, bet, king, queen, jack, ace, suit, winner, game.

*Selecting a scenario and Core classes
**The scenario chosen at the beginning of the session should be simple, clear and well documented
**Related scenarios should be identified and dealt with separately
**Identification of critical classes from the candidate class list is also very important
**This helps to eliminate irrelevant classes and review remaining classes
**This also helps clarify the system scope

For e.g we can apply the elimination process to the candidate class list. We can eliminate blackjack as it is the name of the system. ‘House’ can be eliminated as it is another name for the dealer. Also, instead of making ace, king, queen and jack as separate classes, we can represent them as attributes of individual classes.

*Create initial CRC cards
From the information gathered in the step above, CRC cards are written

[[Image:Deck1.jpg |frame|center|Deck CRC Card]]

[[Image:Dealer.jpg |frame|center|Dealer CRC Card]]

[[Image:Player.jpg |frame|center|Player CRC Card]]

*Creating a CRC Model
**After the CRC cards are written, they are placed appropriately, with collaborating classes closer to each other.
**Accordingly, place each card in position till the entire picture of the system is finalized.
**This process may have to be done in several iterations to get a refined view of the system to be modeled.

For more information on using CRC Cards please refer to http://alistair.cockburn.us/Using+CRC+cards

==CRC Team==

*Domain Experts:
**Core team that writes the cards
**Have good business domain knowledge for which the system is being designed
**Usually are 3-5 people

*Object Oriented Design Analyst:
**Analysts and developers those are familiar with object oriented design methodologies
**Usually are 1-2 people

*Facilitator:
**Most important member who conducts the CRC modeling session
**Acts as an intermediary when there is difference of opinion regarding class responsibilities and paths of collaboration
**Usually a single person

*Scribe:
**Responsible for documenting any business logic that evolves by way of discussions during the CRC modeling process.
**This documentation can be added to the requirements and business documents which can be used by design analysts at a later stage
**Usually are 1-2 people

==Case study==

To understand the working of CRC card modeling better, here is an example of an ATM system designed using CRC cards. Here, the software system under consideration has to control an automated teller machine. The ATM has a magnetic stripe reader for reading an ATM card, a customer console (keyboard and display) for interaction with the customer, a slot for depositing envelopes, a dispenser for cash (in multiples of $20), a printer for printing customer receipts, and a key-operated switch to allow an operator to start or stop the machine. Also, the ATM will communicate with the bank's computer over an appropriate communication link.

To perform a transaction, a customer will be required to insert an ATM card and enter a personal identification number (PIN) - both of which will be sent to the bank for validation. The customer will then be able to perform one or more transactions. The card will be retained in the machine until the customer indicates that there are no further transactions, at which point it will be returned. For more on the case study.

http://www.math-cs.gordon.edu/courses/cps211/ATMExample/CRCCards.html

==Metrics for CRC Analysis==

CRC analysis metrics can help evaluate the level of ease in designing and coding with CRC cards. These metrics also contribute to other project planning factors to give overall sense of project development.These metrics can be calculated easily and quickly without the need of special tools. Three metrics are broadly identified as: maximum depth of inheritance, the number of responsibilities assigned to each class and the number of collaborators for a class. With the example below an attempt has been made to explain these metrics.In the diagram, black line indicates inheritance while blue line indicates collaboration.

[[Image:Class_hierarchy1.png|frame|center|CRC metrics example]]

===Maximum depth of inheritance===

This metric gives an idea of the class hierarchy. It is the count of number of subclasses in the hierarchy.From the diagram,it can be seen that Part Time student is a subclass of Distance Education which in turn is a subclass of student.Thus,maximum depth of inheritance in this case is two with reference to class Student. Each subclass shares the overall functions defined in class Student. For short hierarchies, this is a positive benefit of OO. If number of subclasses become too long, it becomes difficult to trace the flow of functions, resulting in overly complex systems. This makes testing, reviewing and reusing difficult.

===Number of collaborators===

This is the count of all the supporting classes to help a class.In the diagram,there are four collaborators for class Student:Teacher,Library,Computer Labs and Gymnasium.Confusion between collaborators and subclasses may result in creation many collaborators.This will affect the encapsulation of the design.Typical value for this metric is eight.If this value is large,design may be reviewed to see if inheritance is implemented correctly.

===Number of responsibilities===
This is the count of clearly defined set of duties to each class.For example class Student may have functions like Attending Lectures,
Maintaining a certain GPA,Taking the required courses. In this case number of responsibilities is three.Responsibilities should be distributed amongst classes to cover the whole system. This would avoid an imbalance in design. We need to refine the overly complex class into a series of simpler objects. This will make the system easier to understand, implement and reuse. For most commercial transaction oriented systems, values approximately between eight and eighteen are common.

==Advantages==
* CRC cards create a first-cut analysis for complex systems, and let analysts and users examine the operation of discrete subsystems.
* CRC cards are invaluable input into more formal methods. Agile development methods often use CRC cards. They are popular as a front end to UML
* CRC cards are a great way to build teamwork and common understanding.
* Part of the CRC card attraction is their simplicity. Developers can use them with little formal training and just paper and pencil for tools

==Software for CRC card==

It is difficult to maintain, change, share paper based cards for large projects. Software for CRC cards offer many advantages in such scenarios such as

*Easy Revision: As CRC cards are part of development process, constant changes are made by developers to edit the information .Change to one card might require changes to other cards. It becomes difficult to handle such interdependent changes for various fields such as attribute, responsibility, collaboration on paper based system. Software will reflect one change to every corresponding reference in the design. This saves a lot of time and also avoids the manual errors that may be evident on paper based system.

*Easy sharing: Paper based systems make sharing difficult by necessitating team members to be physically present at one location. Using software, team members can work from different locations.

*Better representation: It is possible to group cards from different perspective such as hierarchy, attributes, parent. This helps better understanding and thinking. Some software also aid graphical display of data.

*Inputs to methodologies: Software for CRC cards can provide the input files for UML class diagram generation software saving lot of time in the development cycle.

*Making additions to existing code: Many projects make addition to existing code or reuse already developed code in their project. Software can produce CRC cards with existing source code as an input. This would help the team to understand the code in efficient manner and less time.

However,it comes with a cost.Based on required features and cost,team may select from various commercially available software products.Below are few links:

*quickCRC:http://www.excelsoftware.com/
*CRC card support is part of Visual Paradigm for UML: http://www.visual-paradigm.com/

==CRC cards Limitations and formal object modeling methodologies(UML)==

CRC cards are used to form initial class definitions but alone are not sufficient to be directly coded into software for large systems.It is difficult to keep track of cards as the systems grows and work on subsystems simultaneously and independently.CRC cards lack the notational power to document all the components of a system and cannot provide implementation specifications such as transition states of objects during its life cycle,interface design,data structures,performance and resource utilization. To bridge this gap,more formal object modeling methodology such as UML is used.UML captures the bigger picture.It provides detailed mapping of use cases(operations),object state transitions,inter-process communication functionality,algorithm design.UML is very effective in incremental model of SDLC where lot of details need to captured for precise addition.Information about requirements is represented in detail and whole picture of the system and users is visible.CRC cards are used as effective inputs to UML.CRC card techniques such as brainstorming and role play help enhance functional understanding which helps in preparing better UML use cases.CRC cards given the content for class diagrams,inheritance diagrams,class specifications and object specifications for UML.CRC cards can keep track of attributes that can aid listing them as a part of class specification in UML.Most CRC card software have the facility to export CRC analysis file that can be directly used as an input for UML.Following case study develops UML with the help of CRC cards:

http://www.math.gordon.edu/courses/cs211/ATMExample/

==Summary==
CRC cards are very useful to form the base of object oriented methodology.Techniques such as brain storming and role play enhance the understanding of requirements.CRC automation makes card handling and sharing quick and efficient.For large projects more formal technology such as UML is required but CRC cards can provide a very good starting point.

==Reference==
[1]Introduction to CRC Cards: http://www.softstar-inc.com/Download/Intro%20to%20CRC.pdf
[2]CRC Cards for ATM : http://www.math-cs.gordon.edu/courses/cps211/ATMExample/CRCCards.html
[3]UML methodology for ATM :http://www.math.gordon.edu/courses/cs211/ATMExample/
[4]CRC software:
**quickCRC:http://www.excelsoftware.com/
**Visual Paradigm: http://www.visual-paradigm.com/
[5]Bellin, D and Simone, S.S ‘The CRC Card Book’, Addison Wesely, 1997