Service Oriented Architecture (SOA) And Web Services ...

  • 611 views
Uploaded on

 

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
611
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
21
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide
  • Each of the services described in this chapter are part of a larger service-oriented architecture that uses Web Services. In fact, it is the assembly of such services that makes a service-oriented architecture. An important idea in this chapter is that it will become relatively easy to swap out one service provider for another. This is because of the XML-based standards that are being developed in various industry consortia. A second important idea is that Web Services will cause many services to be seen as commodities. This will result in competition in either cost or innovation within the standards. The next chapter will explain service-oriented architectures and Web Services.
  • If a service-oriented architecture is to be effective, we need a clear understanding of the term service. A service is a function that is well-defined, self-contained, and does not depend on the context or state of other services. Over time, the industry will standardize on the capabilities of various services. The analogy to AV components fits well here. Each is well defined: the industry has decided what are the basic functions of a DVD player, a VCR, and so on. Each AV component is self-contained; you do not need a VCR, for example, to use a CD player. Finally, one AV component does not depend on another component. For example, the television does not need to be on to record using the VCR. True, if you play the recorded tape, you cannot see what is being played when the television is not turned on. Nevertheless, the VCR still does not need to know the context or state of the television. The industry will define standard capabilities of CRM, Enterprise Resource Planning (ERP), and other services. These will become standard services and could, in some ways, be seen as commodities.[ 3 ]We may see these services come in various forms just as we see in buying AV components today. You can buy a DVD player bundled with a VCR or buy each component separately. Nevertheless, over the next few years, the industry will standardize the capabilities of various services much like the AV industry has standardized its components.[ 4 ] What does this mean for software development? It means fewer people writing software and more organizations buying software rather the building it. Continuing with the AV analogy: I am old enough to have built my share of Heathkit electronics products for audio and other systems. (This was much like building your own software.) But the Heathkit era for electronics is over. Yes, I believe a lot of software development will go the same way.
  • Also, other existing connections are in use right now that won’t go away for some time. These include the EDI standards, CORBA, and DCOM to name a few.[ 5 ]Again, much like the connections in AV systems, we can mix and match these connections and upgrade when it makes sense. Connections such as Web Services are part of the inevitable evolution of interconnectedness. Consider how we can now exchange e-mail among disparate products. Although we could not do that at one time, we now take it for granted. This e-mail exchange is possible because of standards. Connections like Web Services (or the equivalent) will also be taken for granted some day because sets of standards will be developed
  • User interfaces invoke services. Many user interfaces can use the same service. A partner may build a user interface on top of a your service, and you may build a user interface on top of a partner’s service.
  • How does a client know what format to use in making a request to a service? For that matter, how do the client and the service know what the request means? The answers to these questions are provided by information in an XML document, called a WSDL document, that contains a description of the web service's interface. A WSDL document contains information specified in Web Service Description Language (WSDL), as defined in the WSDL specification. WSDL defines an XML schema for describing a web service.
  • People familiar with the CORBA standard often remark that Web services are simply CORBA implemented using XML and note the number of features Web services are missing compared to CORBA. Many CORBA deployments are SOAs, in fact, and the original goals of CORBA are very similar to the goals of Web services. Cynics say that CORBA didn't succeed widely because of vendor politics, and there's some truth to that. However, CORBA also hurt itself in its early days by not defining a standard for interoperability. When asked about this, OMG presenters used to say, "It's an exercise left up to the vendors and the customers to work out." The implication, and sometimes the direct statement, was that interoperability didn't matter if you had a standard interface. Web services actually started with SOAP, which is an interoperability standard. Many people still use SOAP without WSDL, which is perfectly possible, indicating another contrast between the two. In CORBA, it's impossible to use the interoperability transport without the interface definition language (IDL)in fact, everything is generated from the IDL. Many Web services toolkits also generate proxies and stubs from WSDL and also generate the SOAP messages. But this is an implementation choice, not part of the SOAP standard. From a technical perspective, it is certainly true that you can use CORBA for almost everything you can use Web services for. And for many applications, CORBA remains a better choice. However, from a human perspective, which is what really counts in the end, if someone is unfamiliar with CORBA or new to distributed computing, Web services are much easier to learn and use, and the missing features don't matter as much as the interoperability.
  • Enterprise integration architecture (EIA) is about being reactive – it's an architecture to facilitate integration of applications that were never designed to work together in the first place. Typically, the primary role of an EIA is synchronizing data among all the disparate systems. So, for example, you might need to make sure a customer's address change is recorded in all different systems that have a copy of the customer record. In contrast SOA is about being proactive – it's an architecture designed to enable applications to work together the day they are deployed. An SOA, instead of focusing on synchronizing multiple copies of redundant data, seeks to avoid the redundancy in the first place – providing a single view and way to manipulate common business entities such as customers, orders, etc. and a single way to define your business processes on top of these – regardless of the underlying applications. Real world architectures, in fact, require a bit of both approaches. You will never be able to fully eliminate redundancy or having processes built into applications if you own and use multiple packaged applications – thus the continued need for EIA. However, for custom applications, overarching business processes, portals, Web sites, dashboards and other similar applications, having these applications use well defined services for common business tasks information access can dramatically improve your time to delivery, total cost of ownership, and – in the end – your business agility.
  • A service is a coarse-grained processing unit that consumes and produces sets of objects passed-by-value. It is not the same as an object in programming language terms. Instead, it is perhaps closer to the concept of a business transaction such as a CICS® or IMS™ A service consists of a collection of components that work in concert to deliver the business function that the service represents. Thus, in comparison, components are finer-grained than services. In addition, while a service maps to a business function, a component typically maps to business entities and the business rules that operate on them.
  • In a component-based design, components are created to closely match business entities (such as Customer, Purchase Order, Order Item) and encapsulate the behavior that matches the entities’ expected behavior. For example, the Purchase Order component provides functions to obtain information about the list of products ordered and the total amount of the order; the Item component provides functions to obtain information about the quantity and price of the product ordered. The implementation of each component is encapsulated behind the interface. So, a user of the Purchase Order component does not know the schema of the Purchase Order table and the algorithm for calculating tax, rebates and/or discounts on the total amount of the order. In a service-oriented design, services are not designed based on business entities. Instead, each service is a holistic unit that manages operations across a set of business entities. For example, a customer service will respond to any request from any other system or service that needs to access customer information. The customer service can process a request to update customer information; add, update, delete investment portfolios; and enquire about the customer’s order history. The customer service owns all the data related to the customers it is managing and is capable of making other service inquiries on behalf of the calling party in order to provide a unified customer service view. This means a service is a manager object that creates and manages its set components.
  • Leverage existing assets. SOAs provide a layer of abstraction that enables an organization to continue leveraging its investment in IT by wrapping these existing assets as services that provide business functions. Organizations potentially can continue getting value out of existing resources instead of having to rebuild from scratch. Easier to integrate and manage complexity. The integration point in a service-oriented architecture is the service specification and not the implementation. This provides implementation transparency and minimizes the impact when infrastructure and implementation changes occur. By providing a service specification in front of existing resources and assets built on disparate systems, integration becomes more manageable since complexities are isolated. This becomes even more important as more businesses work together to provide the value chain. More responsive and faster time-to-market. The ability to compose new services out of existing ones provides a distinct advantage to an organization that has to be agile to respond to demanding business needs. Leveraging existing components and services reduces the time needed to go through the software development life cycle of gathering requirements, performing design, development and testing. This leads to rapid development of new business services and allows an organization to respond quickly to changes and reduce the time-to-market. Reduce cost and increase reuse. With core business services exposed in a loosely coupled manner, they can be more easily used and combined based on business needs. This means less duplication of resources, more potential for reuse, and lower costs. Be ready for what lies ahead. SOAs allows businesses be ready for the future. Business processes which comprise of a series of business services can be more easily created, changed and managed to meet the needs of the time. SOA provides the flexibility and responsiveness that is critical to businesses to survive and thrive. Service-oriented architecture is by no means a silver bullet, and migration to SOA is not an easy task. Rather than migrating the whole enterprise to a service-oriented architecture overnight, the recommended approach is to migrate an appropriate subset of business functions as the business need arises or is anticipated.
  • It is important to point out that Web services are not the only technology that can be used to implement a service-oriented architecture. Many examples of organizations who have successfully implemented service-oriented architectures using other technologies can be found. Web services have also been used by others to implement architectures that are not service-oriented.

Transcript

  • 1. Service Oriented Architecture (SOA) And Web Services By Ahmed Chaudhary
  • 2. Presentation overview
    • Introduction to SOA
      • Through Examples and Metaphors
    • Introduction to Web Services
      • Brief overview of XML Technologies
    • Comparison of SOA and services with other paradigms
    • Benefits and limitations of SOA
  • 3. A business trip in the not so distant future
  • 4.  
  • 5. Information Technology used in this trip
    • Keeping track of all the customer contacts in an online repository
    • Obtaining Company Contact Information from an External Service
    • Online Calendar Services
    • Getting Updates on Clients to Be Visited While on the Road
    • Travel Agency Service
    • Car Rental Service
    • Airlines and Hotel
    • Services as Commodities
  • 6. Another Example
  • 7. SOA Explained
    • A service-oriented architecture is essentially a collection of services.
    • These services communicate with each other
    • Some mechanism of connecting services to each other is needed. Those connections are Web Services.
  • 8. What is a service ?
    • A function that is well-defined
    • Self-contained
    • Does not depend on the context or state of other services.
  • 9. The Mail-Order Business
    • A Mail-Order Business is Asynchronous
      • Work Requests Arrive in Bags of Mail
      • Product Arrives in Shipments
    • Each Message (Order) Is a Transaction
      • Goods Are Prepared and Packed
      • Payment Is Processed
      • Stuff is Shipped
    • Standards and Interchangeability Required
      • Both Goods and Forms
    • Mail-Order Is a Service- Oriented Architecture!
      • Well defined functions
      • Self-contained
      • Independent
  • 10. How Services Work
  • 11. Web Services
    • Web services are the mechanism for connecting services programmatically and are based on standards.
    • Other existing connection mechanisms:
      • CORBA
      • DCOM
      • EDI etc.
  • 12. How Web Services Work
  • 13. More on Web Services
    • Web services can be published, located, and invoked across the Web.
    • The standards required to do so are:
      • Simple Object Access Protocol (SOAP), also known as service-oriented architecture protocol, an XML-based RPC and messaging protocol
      • Web Service Description Language (WSDL), a descriptive interface and protocol binding language
      • Universal Description, Discovery, and Integration (UDDI), a registry mechanism that can be used to look up Web service descriptions
  • 14. Some points about Web Services
    • Services aren’t tied to user interfaces.
    • Services can be implemented in any language, COBOL, Java, etc., but all services must support the same invocation/communication protocols (for example XML/SOAP)
  • 15. Introduction to XML and related Technologies
  • 16. What is XML?
    • XML stands for E X tensible M arkup L anguage
    • XML is a markup language much like HTML
    • XML was designed to describe data
    • XML tags are not predefined. You must define your own tags
  • 17. An Example
  • 18. What is an XML Schema?
    • The purpose of an XML Schema is to define the building blocks of an XML document
      • defines elements that can appear in a document
      • defines which elements are child elements
      • defines the order of elements
      • defines the number of child elements
      • defines data types for elements and attributes
  • 19. What is SOAP?
  • 20. What is WSDL?
    • WSDL stands for Web Services Description Language.
    • WSDL is a document written in XML.
    • The document describes a Web service. It specifies the location of the service and the operations (or methods) the service exposes.
  • 21. Comparisons of SOA
  • 22. SOA vs CORBA & DCOM
  • 23. SOA vs. Enterprise Integration Architecture (EIA)
    • EIA is being reactive
    • SOA is being proactive
  • 24. Services vs. Components
    • A service is a coarse-grained processing and maps to a business function
    • A component typically maps to business entities and the business rules
  • 25. An example component model
  • 26. Revisiting the Business Trip
  • 27.  
  • 28. Why do we need SOA?
    • There's little "green field" anymore
      • New stuff needs existing stuff
      • Existing stuff needs new stuff
    • Heterogeneous Systems
      • No single OS-family / HW-platform
    • Deal with "Big Bang" Effect
      • Everything keeps drifting farther away from everything else
      • Access/Manipulate data from anywhere
  • 29. SOA Benefits
    • Leverage existing assets.
    • Easier to integrate and manage complexity.
    • More responsive and faster time-to-market.
    • Reduce cost and increase reuse.
    • Be ready for what lies ahead.
  • 30. SOA Limitations
    • SOA requires an environmental framework
    • Pending security issues
    • Handling Transactions
  • 31. Summary
    • SOA is an architectural style that encourages the creation of loosely coupled business services Loosely coupled services that are interoperable and technology-agnostic enable business flexibility
    • An SOA solution consists of a composite set of business services that realize an end-to-end business process
    • Each service provides an interface-based service description to support flexible and dynamically re-configurable processes
  • 32. Q & A