Published on

1 Comment
No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • An SOA enables software components to become standard services that can be invoked at runtime or on demand. A business-driven SOA strategy will help focus on the goal of Dynamic Business Interoperability and lead to achievement of desired business outcomes.
  • IT Agility SOA make IT responsive to changing business demands, and more flexible to changing business processes. Reconfiguring loosely coupled business services is simple, fast and low-cost. Maximizing IT Investments SOAs do not rip and replace your current IT application and data assets – they wrap and reuse existing IT investments and make them available to a wider audience. SOA encourages reuse and avoids unnecessary duplication and reinvention. Aligning IT to Business Processes SOAs transform IT systems into self-contained services that accurately reflect business processes and operational requirements. IT mirrors business operations, improving performance. Creating a Standards-Based IT SOAs that use standards-based components provide unparalleled interoperability for all IT systems and services, making IT more flexible and dramatically simplifying integration.
  • Hiding distribution, i.e. the fact that an application is usually made up of many interconnected parts running in distributed locations; Hiding the heterogeneity of the various hardware components, operating systems and communication protocols; Providing uniform, standard, high-level interfaces to the application developers and integrators, so that applications can be easily composed, reused, ported, and made to interoperate; Supplying a set of common services to perform various general purpose functions, in order to avoid duplicating efforts and to facilitate collaboration between applications.
  • SOA-Ch1.ppt

    1. 1. Introduction to Service-Orientation Xiaoying Bai Department of Computer Science and Technology Tsinghua University March 2007
    2. 2. Outline <ul><li>SOA definition and its business and technology values </li></ul><ul><li>Service-orientation vs. object-orientation </li></ul><ul><li>Service-oriented architecture vs. distributed object architecture </li></ul>
    3. 3. What is SOA? <ul><li>Just like object a generation ago, services is now the killer buzzword. However, SOA is a often misunderstood topic in IT today. </li></ul><ul><li>“ My architect thinks it’s service-oriented, my developers insist it’s object-oriented, and my analysts wish it would be more business-oriented. All I can tell you is that it isn’t what it was before we started building Web services.” </li></ul>
    4. 4. What are Services? <ul><li>Services may mean different things to different people: </li></ul><ul><ul><li>Loosely coupled software components that interact with one another dynamically via standard Internet technologies (Gartner). </li></ul></ul><ul><ul><li>A software application identified by a URI, whose interfaces and binding are capable of being defined, described, and discovered by XML artifacts and supports direct interactions with other software applications using XML-based messages via Internet-based protocols (W3C). </li></ul></ul>
    5. 5. What are Services? <ul><ul><li>A piece of business logic accessible via the Internet using open standards (Microsoft). </li></ul></ul><ul><ul><li>Encapsulated, loosely coupled , contracted software functions, offered via standard protocols over the Web (DestiCorp). </li></ul></ul><ul><ul><li>Services are self-contained , reusable software modules that are independent of applications and the computing platforms on which they run. Services have with well-defined interfaces and allow a 1:1 mapping between business tasks and the exact IT components needed to execute the task. (IBM) </li></ul></ul>
    6. 6. What is SOA? <ul><li>SOA definition is still evolving. </li></ul><ul><ul><li>A set of components which can be invoked, and whose interface description can be published and discovered (W3C). </li></ul></ul><ul><ul><li>Service-oriented architecture is a client/server design approach in which an application consists of software services and software service consumers (also known as clients or service requesters). SOA differs from the more general client/server model in its definitive emphasis on loose coupling between software components , and in its use of separately standing interfaces (Gartner). </li></ul></ul>
    7. 7. What is SOA? <ul><ul><li>Service-Oriented Architecture is a business-driven IT architecture approach that supports integrating your business as linked, repeatable business tasks, or services. SOA helps today’s business innovate by ensuring that IT systems can adapt quickly, easily and economically to support rapidly changing business needs. SOA helps customers increase the flexibility of their business processes, strengthen their underlying IT infrastructure and reuse their existing IT investments by creating connections among disparate applications and information sources. (IBM) </li></ul></ul><ul><ul><li>A New Way of Thinking </li></ul></ul>
    8. 8. A CD Player Example <ul><li>Take a CD for instance. If you want to play it, you put your CD into a CD player and the player plays it for you. The CD player offers a CD playing service. Which is nice because you can replace one CD player with another. You can play the same CD on a portable player or on your expensive stereo. They both offer the same CD playing service, but the quality of service is different. </li></ul>
    9. 9. Service broker Component Library Services Business Process The SOA Story Registration Organization X Organization Z Organization Y Found Auto-searchable Application 1 Application 2 Registration Registration
    10. 10. Why Service-Orientation? Distributed Data Distributed Computation Distributed users … ..
    11. 11. Why Service-Orientation? <ul><li>Interoperation issues </li></ul><ul><ul><li>Heterogeneous network protocols </li></ul></ul><ul><ul><li>Heterogeneous hardware platforms </li></ul></ul><ul><ul><li>Heterogeneous operating systems </li></ul></ul><ul><ul><li>Heterogeneous application formats </li></ul></ul><ul><ul><li>…… </li></ul></ul>There must be consensus On Interoperability !
    12. 12. Why Service-Orientation? Changing Market Dynamics Collaborative, integrated value nets Dynamic, adaptive, learning Unpredictable fluctuations Shortening product lifecycle Proactive risk management Increased focus on privacy and security Fixed Costs Proprietary systems Labor-intensive Users adapt to technology Variable costs Open, integrated systems Self-healing, self-managing systems Technology adapts to users Business Technology Business process decision-making Rigid organizational structure Slow and steady economic growth Long-term product lifecycle Passive operational risk management Static On Demand
    13. 13. Why Service-Orientation?
    14. 14. Business Drivers <ul><li>New opportunities </li></ul><ul><ul><li>Innovative products and services from the key differentiator to gain competitive edge. </li></ul></ul><ul><ul><li>Ability to leverage technology to adopt newer business models, thus enabling more channels to earn revenue. </li></ul></ul><ul><li>Cost Savings </li></ul><ul><ul><li>Cost reduction through reduced Total Cost of Ownership adds to the bottom-line. </li></ul></ul><ul><li>Business Agility </li></ul><ul><ul><li>With cut-throat competition, every missed business opportunity positions an enterprise below its competitors. The ability of an enterprise to quickly respond to various business stimuli will be key to survival. </li></ul></ul><ul><ul><li>Faster time to market increases customer satisfaction and also customer loyalty. This results in increased business and higher revenues. </li></ul></ul><ul><ul><li>Ability to provide on demand service, in real-time 24/7. </li></ul></ul><ul><ul><li>Seamless collaboration with partners and customers helps to improve service quality and time to market. </li></ul></ul>
    15. 15. SOA Business Values to IT Management <ul><li>Make interoperability an innate characteristic of IT applications. </li></ul><ul><li>Offer an easy way to speed time-to-market </li></ul><ul><li>Respond quickly to changing business conditions </li></ul><ul><li>Eliminate rework and maximize the value of existing assets. </li></ul>
    16. 16. Technology Drivers <ul><li>Openness </li></ul><ul><ul><li>Dependency on external technology and platform vendors is a risk to an organization on which it has little control. However, adopting open standards mitigates this risk. </li></ul></ul><ul><li>Cost Saving </li></ul><ul><ul><li>Reduction in maintenance cost </li></ul></ul><ul><ul><li>Increased reuse of investment in IT leads in to increased productivity resulting in increased ROI. </li></ul></ul><ul><li>Agility </li></ul><ul><ul><li>Loose coupling increased application agility and reduces time to market for a new application. </li></ul></ul><ul><ul><li>Seamless scalability at minimal cost to cater to seasonal increase in load. </li></ul></ul>
    17. 17. Technology Drivers <ul><li>Software architecture design principles </li></ul><ul><ul><li>Abstraction </li></ul></ul><ul><ul><li>Separation of concerns </li></ul></ul><ul><ul><li>Anticipation of changes </li></ul></ul><ul><ul><li>Design with reuse </li></ul></ul>
    18. 18. Related Concepts SOA Object Oriented CBSD Web Application Distributed Computing BPM Enterprise Integration CBSD: Component-Based Software Development BPM: Business Process Management
    19. 19. SOA Evolution Program Paradigm Distributed Computing 1950 1960 1970 1980 1990 2000 Assembler COBOL SIMULA Pascal Modular2 Smalltalk PROLOG Ada C++ Java C# VT3270 VT100 Client/Server RPC Stored Procedure TCP/IP CORBA EAI WWW MQ EJB NFS WSDL SOAP SOA
    20. 20. SOA Characteristics <ul><li>Based on open standards </li></ul><ul><li>Foster inherent reusability </li></ul><ul><li>Foster intrinsic interoperability </li></ul><ul><li>Emphasizes extensibility </li></ul><ul><li>Fundamentally autonomous </li></ul><ul><li>Promotes dynamic discovery </li></ul><ul><li>Promotes architectural composability </li></ul><ul><li>Promotes loose coupling throughout the enterprise </li></ul><ul><li>Supports incremental implementation </li></ul>
    21. 21. SOA Potential Benefits <ul><li>Improved Integration, intrinsic interoperability </li></ul><ul><li>Inherent reuse </li></ul><ul><li>Streamlined architectures and solutions </li></ul><ul><li>Leveraging the legacy investment </li></ul><ul><li>Establishing standardized XML data representation </li></ul><ul><li>Focused investment on communications infrastructure </li></ul><ul><li>Best-of-breed alternatives </li></ul><ul><li>Organizational agility </li></ul>
    22. 22. SOA Principles <ul><li>The business drives the services, and the services drive the technology. </li></ul><ul><li>Business agility is a fundamental business requirement. </li></ul><ul><li>A successful SOA is always in flux. </li></ul>
    23. 23. SOA Standards Organizations Basic Profile, Basic Security Profile UDDI, ebXML, SAML, XACML, WS-BPEL, WS-Security XML, XML Schema, XQuery, XML Encryption, XML Signature, XPath, XSLT, WSDL, SOAP, WS-CDL, WS-Addressing, Web Services Architecture SOA deliverables To foster standardized interoperability using Web services standards. To promote online trade and commerce via specialized Web services standards. To further the evolution of the Web, by providing fundamental standards that improve online business and information sharing. SOA goal 200 600 400 Approximate membership 2002 1993 as SGML Open, 1994 as OASIS 1994 Established WS-I OASIS W3C
    24. 24. Service Orientation vs. Object Orientation
    25. 25. Conceptual Relationship <ul><li>Several principles of service-orientation are related to and derived from object-orientation principles. </li></ul><ul><ul><li>abstraction -- decomposition </li></ul></ul><ul><ul><li>Encapsulation -- Reusability </li></ul></ul><ul><ul><li>Interface first -- Loose coupling </li></ul></ul><ul><ul><li>Composition -- Autonomy </li></ul></ul><ul><ul><li>Statelessness -- Discoverability </li></ul></ul><ul><li>Some object-orientation principles, such as inheritance, do not fit into the service-orientation world. </li></ul><ul><li>Some service-orientation principles, such as loose coupling and autonomy, are not directly promoted by object-orientation. </li></ul>
    26. 26. Conceptual Differences Loose coupling between units of processing logic. Based on predefined class dependencies, resulting in more tightly bound objects. Coarse-grained interfaces (service description) Message-based communication Fine-grained interfaces (APIs), Communication based on RPC or local API calls. Large unit of processing logic (service), May vary significantly in scope. Unit of logic (object) tend to be smaller and More specific in scope. Promotes the creation of activity-agnostic units of processing logic (services) that are driven into action by intelligent units of communication (message). Encourages the binding of processing logic with data, resulting in highly intelligent units (object). Prefers that units of processing logic (services) be designed to remain as stateless as possible. Promotes binding of data and logic, resulting In the creation of more stateful units (objects). Service-Orientation Object-Orientation
    27. 27. The Paradigm Shift Object-Oriented Concept & Architecture Service-Oriented Concept & Architecture Simula Smalltalk Objective C C++ Java Programming Language XML UDDI ebXML WSDL SOAP OWL Standard Specification UML Modeling BPEL WSFL XLANG Modeling OOAD OO Framework OODB OO Process model Technology & Methodology MDA SO Framework Ontology / Service DB SO lifecycle process Technology & Methodology
    28. 28. Service Oriented Architecture vs. Distributed Object Architecture
    29. 29. Conceptual Relationship <ul><li>SOA is a radical departure from client-server architecture. Current SOAs still employ some of the technologies originally used to build client-server applications. Though more sophisticated, SOAs introduce complexity that sharply contrasts the simplicity of a two-tier client-server architecture. </li></ul><ul><li>Distributed Internet architecture has much in common with SOA, including a significant amount of its technology. However, SOA has distinct characteristics relating to both technology and its underlying design principles. </li></ul>
    30. 30. Distributed System Architecture Client Presentation Client Presentation Application Processing Two Tier with Thin Client Two Tier with Fat Client Client Presentation Three Tier Server Data Management Application Processing Server Data Management Server Application Processing Server Data Management
    31. 31. Multi-Tier System Architecture <ul><li>RPC-based </li></ul><ul><ul><li>Client and middleware server is tightly coupled </li></ul></ul><ul><li>Remote Object based </li></ul><ul><ul><li>Remote objects communicates through standard interface languages </li></ul></ul><ul><ul><li>Object models: OMG CORBA, SUN Java RMI, MS DCOM </li></ul></ul><ul><li>Web based </li></ul><ul><ul><li>Browser + “Dynamic content generation” </li></ul></ul><ul><ul><li>Enabling techniques: CGI, Java Servlet/JSP, MS ASP </li></ul></ul>
    32. 32. Distributed Object Computing <ul><li>Coupled with a powerful communications infrastructure, distributed objects divide monolithic client/server applications into self-managing components, or objects, that can interoperate across disparate networks and operating systems. </li></ul><ul><ul><li>SUN J2EE </li></ul></ul><ul><ul><ul><li>Java TM 2 Platform, Enterprise Edition </li></ul></ul></ul><ul><ul><li>MS DCOM </li></ul></ul><ul><ul><ul><li>Distributed Component Object Model </li></ul></ul></ul><ul><ul><li>OMG CORBA </li></ul></ul><ul><ul><ul><li>Common Object Request Broker Architecture </li></ul></ul></ul>
    33. 33. Middleware <ul><li>In a distributed computing system, middleware is defined as the software layer that lies between the operating system and the applications on each site of the system. It serves to &quot;glue together&quot; or mediate between separate components. </li></ul><ul><li>Objectives </li></ul><ul><ul><li>Hiding distribution </li></ul></ul><ul><ul><li>Hiding the heterogeneity </li></ul></ul><ul><ul><li>Providing uniform, standard, high-level interfaces </li></ul></ul><ul><ul><li>Supplying a set of common services </li></ul></ul><ul><li>Examples </li></ul><ul><ul><li>Transaction processing monitors </li></ul></ul><ul><ul><li>Data converters </li></ul></ul><ul><ul><li>Communication controllers </li></ul></ul>
    34. 34. Middleware <ul><li>Design Challenges </li></ul><ul><ul><li>Performance </li></ul></ul><ul><ul><li>Scalability </li></ul></ul><ul><ul><li>Complexity of administration </li></ul></ul><ul><ul><li>Mobility and dynamic reconfiguration </li></ul></ul><ul><ul><li>Global information network to manage large applications that are heterogeneous, widely distributed and in permanent evolution </li></ul></ul>
    35. 35. CORBA – A bit of history <ul><li>OMG Standard, “to allow applications to communicate with one another no matter where they are located or who has designed them” </li></ul><ul><ul><li>1991, CORBA 1.1, IDL & API within an ORB </li></ul></ul><ul><ul><li>1994, CORBA interoperability & IIOP (Internet Inter-ORB Protocol) </li></ul></ul><ul><ul><li>2002, CORBA Component Model </li></ul></ul>
    36. 36. CORBA – Objectives <ul><li>Distributed object computing middleware that shields applications from heterogeneous platform dependencies. </li></ul><ul><li>To simplify development of distributed applications by automating/encapsulating </li></ul><ul><ul><li>Object location </li></ul></ul><ul><ul><li>Connection & memory mgmt. </li></ul></ul><ul><ul><li>Parameter (de)marshaling </li></ul></ul><ul><ul><li>Event & request demultiplexing </li></ul></ul><ul><ul><li>Error handling & fault tolerance </li></ul></ul><ul><ul><li>Object/server activation </li></ul></ul><ul><ul><li>Concurrency </li></ul></ul><ul><ul><li>Security </li></ul></ul><ul><li>CORBA defines interfaces , not implementations </li></ul>
    37. 37. CORBA Application Structure <ul><li>Object Request Broker : enables objects to transparently make and receive requests and responses in a distributed environment. </li></ul><ul><ul><li>The core of the reference model, “telephone exchange” </li></ul></ul><ul><li>Object Services : a collection of services (interfaces and objects) that support basic functions for using and implementing objects. </li></ul><ul><ul><li>e.g. Naming, Trading, and Life Cycle Service </li></ul></ul><ul><li>Common Facilities : a collection of services that many applications may share, but which are not as fundamental as the Object Services </li></ul><ul><ul><li>e.g. e-mail facility </li></ul></ul><ul><li>Application Objects : products of a single vendor on in-house development group that controls their interfaces. </li></ul>
    38. 38. CORBA Application Structure Object Request Broker Application Objects Domain Facilities Horizontal CORBA Facilities Domain Facilities
    39. 39. CORBA Middleware Architecture Interface Repository Implementation Repository IDL Compiler Client Object Dynamic Invocation IDL Stub ORB Interface IDL Skeleton Dynamic Skeleton Object Adapter ORB Core GIOP/IIOP/ESIOPS
    40. 40. Object Request Broker (ORB) <ul><li>A logical set of services </li></ul><ul><ul><li>Locates the remote object, communicates the request, waits for the results and when available communicates the results back to the client </li></ul></ul><ul><ul><li>Location transparency </li></ul></ul><ul><ul><li>Programming language independent: interface translation and language binding </li></ul></ul>Client Object Object Request Broker (ORB)
    41. 41. Interface Definition Language (IDL) <ul><li>Language neutral, Language mapping </li></ul><ul><ul><li>Modularized object interface </li></ul></ul><ul><ul><li>Operations and attributes that an object supports </li></ul></ul><ul><ul><li>Exceptions raised by an operation </li></ul></ul><ul><ul><li>Data types of an operation return value, its parameters, and an object’s attributes </li></ul></ul>Client Object Request Broker (ORB) IDL Stub IDL Skeleton Object
    42. 42. Two-way Processing ORB CORE In args Object Client Obj. ref. Operation () Out args + return value IDL Stub 1C Locate target object 3C 2C Send request to server Wait for request to complete Implementation Repository 1S Activate server IDL Skeleton 2S Activate Object’s Servant 3S Process Request 4S Return Request 4C Return Control to Client
    43. 43. CORBA Interoperability <ul><li>Motivation </li></ul><ul><ul><li>ORB implementation diversity </li></ul></ul><ul><ul><li>ORB boundaries: </li></ul></ul><ul><ul><ul><li>Partition the environment into different ORBs </li></ul></ul></ul><ul><ul><ul><li>Simplified test, management, and maintenance </li></ul></ul></ul><ul><ul><ul><li>Decentralized control </li></ul></ul></ul><ul><ul><ul><li>e.g. internet ORB, company ORB </li></ul></ul></ul><ul><ul><li>ORB vary in scope, distance and lifetime </li></ul></ul><ul><ul><ul><li>e.g. archives ORB, game ORB </li></ul></ul></ul><ul><li>Elements </li></ul><ul><ul><li>Inter-ORB Bridge: transactions between ORB domains </li></ul></ul><ul><ul><li>General Inter-ORB Protocol (GIOP): ORB-ORB interactions over connection-oriented transport protocol </li></ul></ul><ul><ul><li>Internet Inter-ORB Protocol (IIOP): ORB-ORB communication across the Internet (TCP/IP) </li></ul></ul>
    44. 44. CORBA Interoperability Client ORB 1 IDL Stub IDL Skeleton Object Client IDL Skeleton Object ORB 2 IDL Stub IIOP Interoperability uses ORB-to-ORB communication
    45. 45. CORBA Services Support queries on objects Query Supports the finding of CORBA objects based on properties describing the services offered by the object Trading Supports the association of name-value pairs with CORBA objects Property Provides a locking service for CORBA objects in order to ensure serialized access Concurrency Control Coordinates atomic access to CORBA objects Transactions Coordinates the transformation of CORBA objects to and from external media Externalization Provides arbitrary typed n-ray relationships between CORBA objects Relationships Decouple the communication between distributed objects Events Define how CORBA objects can have friendly symbolic names Naming Define how CORBA objects are created, removed, moved and copied Object Life Cycle Description Services
    46. 46. J2EE <ul><li>A platform for developing applications </li></ul><ul><ul><li>Oct. 1994, Public introduction of Java </li></ul></ul><ul><ul><li>Jan. 1996, JDK 1.0 released </li></ul></ul><ul><ul><li>Apr. 1997, EJB specification announced </li></ul></ul><ul><ul><li>Dec. 1998, Java 2, SDK 1.2 released </li></ul></ul><ul><ul><li>Jun. 1999, J2EE announced </li></ul></ul><ul><ul><li>Dec. 1999, J2EE platform released </li></ul></ul><ul><ul><li>Sep. 2001, J2EE 1.3 released </li></ul></ul><ul><ul><li>Nov. 2003, J2EE 1.4 released </li></ul></ul>
    47. 47. Pure HTML Java Applet Browser Java Application Desktop J2EE Client Other Device Client Side Presentation Server Side Presentation JSP Java Servlet Web Server JSP J2EE platform Server Side Business Logic EJB EJB EJB Container EJB J2EE platform Enterprise Information System J2EE Application Architecture
    48. 48. J2EE Middleware Architecture
    49. 49. J2EE Interoperability
    50. 50. J2EE Services <ul><li>HTTP/HTTPS </li></ul><ul><li>JAAS – Java Authorization and Authentication Service </li></ul><ul><li>JTA – Java Transaction API </li></ul><ul><li>JNDI – Java Naming and Directory Service </li></ul><ul><li>RMI-IIOP </li></ul><ul><li>JDBC – Java DataBase Connectivity </li></ul><ul><li>JMS – Java Message Service </li></ul><ul><li>JavaMail </li></ul><ul><li>JAXP – Java API for XML Parsing </li></ul><ul><li>Java IDL </li></ul><ul><li>…… </li></ul>
    51. 51. Advantages of Distributed Object Architecture <ul><li>It allows the system designer to delay decisions on where and how services should be provided </li></ul><ul><li>It is a very open system architecture that allows new resources to be added to it as required </li></ul><ul><li>The system is flexible and scaleable </li></ul><ul><li>It is possible to reconfigure the system dynamically with objects migrating across the network as required </li></ul>
    52. 52. Weakness of Distributed Object Architecture <ul><li>Tightly coupled </li></ul><ul><ul><li>Both ends of each distributed computing link had to agree on the details of the API. A code change to a COM object, for example, required corresponding changes to the code accessing that object. </li></ul></ul><ul><li>Proprietary </li></ul><ul><ul><li>Microsoft controlled DCOM </li></ul></ul><ul><ul><li>Implementing a CORBA architecture typically necessitated the decision to work with a single vendor's implementation of the specification. </li></ul></ul>
    53. 53. SOA -- Evolution vs. Revolution <ul><li>SOA is developed upon the weaknesses of distribute object computing technique. </li></ul><ul><ul><li>Standard-based </li></ul></ul><ul><ul><ul><li>Reliance upon universally accepted standards provides broad interoperability among different vendors’ solutions </li></ul></ul></ul><ul><ul><li>loosely couples </li></ul></ul><ul><ul><ul><li>Separates the participants in distributed computing interactions so that modifying the interface of one participant in the exchange does not break the other. </li></ul></ul></ul>
    54. 54. Summary <ul><li>SOA enables dynamic collaboration among loosely coupled, reusable software components through standard Internet protocols. </li></ul><ul><li>SOA is driven by both business and technology needs for open collaboration, cost saving and flexibility to dynamic changes. </li></ul><ul><li>SOA is developed from other software techniques including distributed object computing, component-based software engineering, and enterprise application integration. </li></ul>
    55. 55. References <ul><li>M. P. Singh and M. N. Huhns, “Service-Oriented Computing”, John Wiley & Sons, 2005. </li></ul><ul><li>Thomas Erl, “Service-Oriented Architecture: Concepts, Technology, and Design”, Prentice Hall, 2005. </li></ul><ul><li>Eric Newcomer and Greg Lomow, “Understanding SOA with Web Services”, Addison Wesley, 2005. </li></ul><ul><li>D. Krafzig, K. Banke and D. Slama, “Enterprise SOA: Service-Oriented Architecture Best Practice”, Prentice Hall, 2005. </li></ul><ul><li>Wei-Tek Tsai, “What is SOA? Why should you care?”, Tsinghua University Short Course on Service-Oriented Computing and Architecture, 2006. </li></ul><ul><li>Jen-Yao Chung, “Service-Oriented Architecture and Web Services”, keynote speaking, SOSE 2005. </li></ul>
    56. 56. References <ul><li>Jason Bloomberg, “Principles of SOA”, Feb. 2003. </li></ul><ul><li>“ A Practical Guide to SOA for IT Management”, Systinet Corp. 2005. </li></ul><ul><li>Shireesh Jayashetty, Pradeep Kumar M, “Adopting Service Oriented Architecture increases the flexibility of your enterprise”, Infosys, 2006. </li></ul><ul><li>Ian Summerville, “Software Engineering” (6 th Edition), Addison-Wesley, 2000. </li></ul><ul><li>ObjectWeb, http:// / </li></ul><ul><li>OMG, </li></ul><ul><li>Doug Schmidt’s CORBA page, http:// </li></ul><ul><li>IBM SOA glossary, </li></ul>