CSC/ECE 517 Fall 2009/wiki2 17 f1: Difference between revisions
No edit summary |
No edit summary |
||
Line 18: | Line 18: | ||
* '''Secure''' - It should not be easily hackable | * '''Secure''' - It should not be easily hackable | ||
== Core Components of SOA== | === Core Components of SOA=== | ||
* '''SOAP''': Simple Object Access Protocol - As a layman's example of how SOAP procedures can be used, a SOAP message could be sent to a web service enabled web site (for example, a house price database) with the parameters needed for a search. The site would then return an [http://en.wikipedia.org/wiki/XML XML]-formatted document with the resulting data (prices, location, features, etc). Because the data is returned in a standardized machine-parseable format, it could then be integrated directly into a third-party site. | * '''SOAP''': Simple Object Access Protocol - As a layman's example of how SOAP procedures can be used, a SOAP message could be sent to a web service enabled web site (for example, a house price database) with the parameters needed for a search. The site would then return an [http://en.wikipedia.org/wiki/XML XML]-formatted document with the resulting data (prices, location, features, etc). Because the data is returned in a standardized machine-parseable format, it could then be integrated directly into a third-party site. | ||
* '''WSDL''': Web Services Description Language - Its an XML-based language that provides a model for describing Web Services. | * '''WSDL''': Web Services Description Language - Its an XML-based language that provides a model for describing Web Services. | ||
Line 26: | Line 26: | ||
* '''WS-*''': Web Services Standards - a collection of protocols and standards used for exchanging data between applications | * '''WS-*''': Web Services Standards - a collection of protocols and standards used for exchanging data between applications | ||
==Benefits of SOA == | ===Benefits of SOA === | ||
* Improve long-term value of software assets | * Improve long-term value of software assets | ||
* Improve quality through modularity and testability | * Improve quality through modularity and testability | ||
Line 33: | Line 33: | ||
* Avoid vendor and platform lock-in | * Avoid vendor and platform lock-in | ||
* Integrate with [http://en.wikipedia.org/wiki/Enterprise_resource_planning ERPs] and Enterprise infrastructure software | * Integrate with [http://en.wikipedia.org/wiki/Enterprise_resource_planning ERPs] and Enterprise infrastructure software | ||
===Use cases for SOA with Ruby=== | |||
Ruby can be a productive way to: | |||
* Build web applications over web services | |||
* Write web services tests with minimal code | |||
* Write custom web services monitoring and management | |||
* Integrate ERPs, [http://en.wikipedia.org/wiki/Commercial_off-the-shelf COTS] and custom applications | |||
* Write SOA glue-code, e.g. custom transformation | |||
* Perform programmatic web services orchestration | |||
* Develop basic web services |
Revision as of 21:38, 8 October 2009
Service Oriented Architecture provides another view of providing functionality based upon services offered in terms of protocols and a specific API. To provide services, platforms rely upon principles and the power that can be expressed through reflection and meta programming. Research and report how these critical concepts relate to and support SOA.
Service Oriented Architectures
Service Oriented Architecture is a paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains. It provides a uniform means to offer, discover, interact with and use capabilities to produce desired effects consistent with measurable preconditions and expectations.
This makes it easier for software integration of different modules developed by different people. Rather than defining an API, SOA defines the interface in terms of protocols and functionality such that modules following these protocols can easily be integrated together. The main characteristics of SOA are:
- Based on open standards - The governing principles are free for all to use and not protected by intellectual property.
- Interoperable - Diverse systems should be able to work together (inter-operate)
- Autonomous - Services have control over the logic they encapsulate.
- Reusable - Logic is divided into services with the intention of promoting reuse.
- Reliable - It should not have many flaws
- Discoverable - Services are designed to be outwardly descriptive so that they can be found and assessed via available discovery mechanisms
- Loosely-Coupled - Loose coupling occurs when the dependent class contains a pointer only to an interface, which can then be implemented by one or many concrete classes.
- Stateless - Should exhibit the same behaviour and yield the same result whether called once, or 100 times
- Composable - Collections of services can be coordinated and assembled to form composite services.
- Manageable - It should be easy to maintain it
- Secure - It should not be easily hackable
Core Components of SOA
- SOAP: Simple Object Access Protocol - As a layman's example of how SOAP procedures can be used, a SOAP message could be sent to a web service enabled web site (for example, a house price database) with the parameters needed for a search. The site would then return an XML-formatted document with the resulting data (prices, location, features, etc). Because the data is returned in a standardized machine-parseable format, it could then be integrated directly into a third-party site.
- WSDL: Web Services Description Language - Its an XML-based language that provides a model for describing Web Services.
- UDDI: Universal Discovery, Definition and Integration - Its an XML-based database for companies world-wide to list themselves on the internet
- BPEL: Business Process Execution Language - Its a language for specifying interaction with web services.
- ESB: Enterprise Service Bus
- WS-*: Web Services Standards - a collection of protocols and standards used for exchanging data between applications
Benefits of SOA
- Improve long-term value of software assets
- Improve quality through modularity and testability
- Reduce development time with composition and reusability
- Leverage heterogeneous development environments
- Avoid vendor and platform lock-in
- Integrate with ERPs and Enterprise infrastructure software
Use cases for SOA with Ruby
Ruby can be a productive way to:
- Build web applications over web services
- Write web services tests with minimal code
- Write custom web services monitoring and management
- Integrate ERPs, COTS and custom applications
- Write SOA glue-code, e.g. custom transformation
- Perform programmatic web services orchestration
- Develop basic web services