What is SOA?
SOA is not a technology – it is an architecture and strategy.
SOA architecture principles are:
Loose Coupling - Services maintain a relationship that minimizes dependencies and only requires that they retain an awareness of each other.
Service Contract - Services adhere to a communication agreement, as defined collectively by one or more service description and related documents.
Autonomy - Services have control over the logic they encapsulate.
Abstraction - Beyond what is described in the service contract, service hide logic from outside world.
Reusability - Services should be developed with the intention of promoting reuse.
Composability - Collections of services can be coordinated and assembled to form composite services.
Statelessness - Services minimize retaining information specific to an activity.
Discoverability - Services can be found and assessed via available discovery mechanism.
What is WOA?
WOA stands for web-oriented architecture. It's the next evolutionary step for SOA, lightweight version of SOA, as WOA is a resource-oriented rather then service-oriented.
WOA is simply a way of implementing SOA by creating services that are RESTful resources, allowing any service or data to be accessed with a URI. It is a solution of the REST style for building Web services based on straight HTTP and XML documents.
According to Gartner vice president Nick Gall:“WOA meant to me was a more Web-centric style of doing Web services: Simpler, less complex, less vendor-driven, just a catch-all for this different style that was emerging.”
Nick simply describes, WOA = SOA + WWW + REST
According to Dana Gardner :“WOA, isn’t an architecture, it’s a webby style of apps and integration, of mashups and open APIs, of using REST and RIA clients, all from a variety of Internet sources.”
Following picture to describe trends adapted by IT industry from 1970 to the near future:
According to Dana Gardner :“WOA, isn’t an architecture, it’s a webby style of apps and integration, of mashups and open APIs, of using REST and RIA clients, all from a variety of Internet sources.”
Following picture to describe trends adapted by IT industry from 1970 to the near future:
Trade Offs between SOA and WOA?
SOA talks lot about connecting application and database together, while WOA, apart from technology describes opportunity to connect people together and to support their collaborative efforts.
Traditional SOA builds a messaging layer above HTTP using SOAP, while WOA uses Plain Old XML over HTTP (POX/HTTP).
SOA uses WS-Security and another sophisticated standard for security, and WOA uses HTTPS. In the WS-* space a lot of options available for building secure applications, while for WOA security is still a concern as HTTP security relies more on infrastructure and thus not as sophisticated as WS-Security.
WOA uses well-established Web methods (POST, GET, PUT and DELETE) for interacting with services and lessen the dependence on proprietary middleware to coordinate service interaction and shift to common Web infrastructure. In contrarily, SOA development requires good amount of investment from organization to buy middleware products.
SOA uses system-level architectural style (how to implement your service) whereas WOA refers to interface-level architectural style (how to expose those service to users). SOA better suited for system-to-system integration while WOA is for user-to-system integration.
WOA build using light weight scripting vs. SOA requires complex .NET or java programming.
SOA implementation requires XML schema's for service contracts, while WOA just says go ahead and implement the web service in consumer required format.
SOA talks lot about connecting application and database together, while WOA, apart from technology describes opportunity to connect people together and to support their collaborative efforts.
Traditional SOA builds a messaging layer above HTTP using SOAP, while WOA uses Plain Old XML over HTTP (POX/HTTP).
SOA uses WS-Security and another sophisticated standard for security, and WOA uses HTTPS. In the WS-* space a lot of options available for building secure applications, while for WOA security is still a concern as HTTP security relies more on infrastructure and thus not as sophisticated as WS-Security.
WOA uses well-established Web methods (POST, GET, PUT and DELETE) for interacting with services and lessen the dependence on proprietary middleware to coordinate service interaction and shift to common Web infrastructure. In contrarily, SOA development requires good amount of investment from organization to buy middleware products.
SOA uses system-level architectural style (how to implement your service) whereas WOA refers to interface-level architectural style (how to expose those service to users). SOA better suited for system-to-system integration while WOA is for user-to-system integration.
WOA build using light weight scripting vs. SOA requires complex .NET or java programming.
SOA implementation requires XML schema's for service contracts, while WOA just says go ahead and implement the web service in consumer required format.
Common Challenges in building SOA and WOA?
Most of time SOA and WOA development started by consulting company. And consulting company knows about the technology not about the business of the client. Lack of resources from Client Company at early stage lead towards bad architectural decisions and at the same time very few employee of Client Company gets awareness of new technology.
Too volatile requirement creates confusion in development team to define a clear line between current and next iteration and leads for bigger development cycle as well as complex change management system.
In a large organization lack of ownership and accountability from different team will lead for greater development cycle because of unavailability of basic infrastructure, required services etc.
Complexity of SOA (i.e. WS-* architecture) creates need for SOA governance. Without formal SOA governance SOA project can’t be successful. While WOA avoids many of the complexity of SOA, still needs good governance in place.
Conclusion
WOA and SOA are complementary architectural styles. In some cases, a WOA will serve the purpose. In others, architect may need to scale up to a SOA solution.
There is a place for SOA and WOA both, as WOA can be used for simple web based interface. A plethora of WS-* standards exist specifically to address the complexity of enterprise integration and interaction needs.
Though lighter weight WOA looks superior, limitation of no industry standard profiles for complex services in WOA advises not to ignore SOA. There is more work to be done in WOA world to figure out how governance, security, orchestration and others issues look like.
According to Leo Shuster, REST should be used when performance and simplicity are paramount, very less security is required and no complex interaction between consumer and services are necessary. In other cases SOA can be a better choice.
Complexity of SOA (i.e. WS-* architecture) creates need for SOA governance. Without formal SOA governance SOA project can’t be successful. While WOA avoids many of the complexity of SOA, still needs good governance in place.
Conclusion
WOA and SOA are complementary architectural styles. In some cases, a WOA will serve the purpose. In others, architect may need to scale up to a SOA solution.
There is a place for SOA and WOA both, as WOA can be used for simple web based interface. A plethora of WS-* standards exist specifically to address the complexity of enterprise integration and interaction needs.
Though lighter weight WOA looks superior, limitation of no industry standard profiles for complex services in WOA advises not to ignore SOA. There is more work to be done in WOA world to figure out how governance, security, orchestration and others issues look like.
According to Leo Shuster, REST should be used when performance and simplicity are paramount, very less security is required and no complex interaction between consumer and services are necessary. In other cases SOA can be a better choice.
No comments:
Post a Comment