Soa overview
Download as PPTX, PDF•0 likes•532 views
The document discusses Service Oriented Architecture (SOA), defining it as an architectural style for building systems based on interacting coarse-grained autonomous components called services. It outlines the basic SOA components - services, contracts, endpoints, messages, and policies. Services expose behavior through contracts composed of messages sent to discoverable endpoints. Behavior is governed by externally defined policies. The document also discusses best practices, the past and future of SOA, and introduces the concept of Cloud Service Oriented Architecture (C-SOA).
Soa overview
- 4. In order to be able to converge between the technical and business viewpoints we first need to differentiate between an architectural style and its application – once we define what SOA is we can apply it at an organization level to get an SOA initiative where services will encapsulate business function. However we can also apply SOA on a single project and get services whose content revolves around technical issues like security or management.
- 5. We also need to differentiate between design goals such as loose coupling or business alignment and architectural building blocks and constraints like coarse grained services or policy based interactions
- 6. Based on that we can define Service Oriented Architecture as an architectural style for building systems based on interacting coarse grained autonomous components called services. Each service expose processes and behavior through contracts, which are composed of messages at discoverable addresses called endpoints. Services’ behavior is governed by policies which are set externally to the service itself. Now lets figure out basic SOA components and their relations:
- 8. Service The central pillar of SOA is the service. A Service should provide a high cohesion and distinct function. Services should be coarse grained pieces of logic. A Service should implement at least all the functionality promised by the contracts it exposes. One of the characteristics of services is service autonomy. Autonomy means the services should be self-sufficient, at least to some extent, and manifest self healing properties.
- 9. Contract The collection of all the messages supported by the Service is collectively known as the service's contract. The contract can be unilateral, meaning a closed set of messages the service chooses to provide. A contract might also be multilateral or bilateral, that is, between a predefined group of parties. The contract can be considered the interface of the Service akin to interfaces of object in object oriented languages.
- 10. End Point The Endpoint is an address, a URI, a specific place where the service can be found and consumed. A specific contract can be exposed at a specific endpoint.
- 11. Message The unit of communication in SOA is the message. Messages can come in different forms and shapes, for instance, http GET messages (part of the REST style) ,SOAP messages, JMS messages and even SMTP messages are all valid message forms.
- 12. Policy One important differentiator between Object Orientation or Component Orientation and SOA is the existence of policy. If an interface or contract in SOA lingo, separates specification from implementation. Policy separates dynamic specification from static/semantic specification. Policy represents the conditions for the semantic specification availability for service consumers. The unique aspects of policy are that it can be updated in run-time and that it is externalized from the business logic. The Policy specify dynamic properties like security (encryption, authentication, Id etc.) , auditing, SLA etc.
- 13. Service Consumer A service doesn’t mean much if there isn’t someone/something in the world that uses it. So to complete the SOA picture we need Service Consumers. A service consumer is any software that interacts with a service by exchanging messages with the service. Consumers can be either client applications or other "neighboring” services their only requirement is that they bind to an SOA contract.
- 14. Best Practices
- 15. A recent white paper from IBM Global Services describes the lessons applied by IBM’s Academy of Technology to achieve success in their SOA implementations. They did that by focusing on five priorities: Develop architecture with a vision for the future - looking beyond simple connectivity and focusing more on architecture is the most common recurring need for SOA implementations. Foresee linkages from IT to your business processes - implementation of an architecture that transitions IT into the role of a service provider for business functionality. Create an organizational structure to support SOA including culture, skills, training, teaming, organization structure, decision making, reward systems, collaboration and governance. Build a scalable infrastructure - create a baseline for your services performance and scalability using appropriate instruments and measurements. Enable operational visibility - focus on governance and service management.
- 16. SOA: Past n Future
- 17. SOA: The Past Businesses have spent the last fifteen years trying to come up with a set standard. While CORBA and DCOM have been in existence for a while, they never became worldwide standards. Internet has set up standards in more than one way viz., HTTP and HTML, which link together people all over the globe. Businesses witnessing the growth and the development of the Internet decided to use similar strategies to link their own computer systems together. Such Businesses first came up with Web services standards which were based on technologies that originated on the Internet and made use of technologies such as XML and HTTP as a means for representing software parts and linking together a number of different computer systems. There has been an adoption of web services as the standards to base Service Oriented Architecture. Software vendors such as webMethods have brought out a variety of products onto the market that have made Service Oriented Architecture quite useful.
- 18. SOA: The Future In recent years there have been meaningful debate on what standards Service Oriented Architecture should be based upon in order to optimize functionality in future scenarios The services themselves have to be oriented towards Business if you expect Business people to orchestrate them.
- 19. Cloud Service Oriented Architecture (C- SOA) is an architectural approach to leverage cloud computing resources while utilizing Service Oriented Architecture (SOA) disciplines to drive substantial business value. In this convergence, SOA provides the underlying enterprise platform to consume cloud services. Historically, as business requirements evolved, enterprises continued to deploy new systems for almost every new application suite. The benefits of C-SOA include: Increased collaboration and federation Improved interoperability and agility Aligned business and IT goals and efforts Diversified choice of service providers Increased ROI while reducing IT operating cost and overhead