Service-oriented Architecture with Respect to Reusability


Published on

In this talk, Service-oriented Architecture is considered with respect to re-usability.

Published in: Technology
  • Be the first to comment

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

No notes for slide

Service-oriented Architecture with Respect to Reusability

  1. 1. An Introduction toService Oriented Development with respect to ReusabilityShahid Bahonar University of Kerman
  2. 2. Supervised by: Prof. H. Sanat NamaProf. of Computer Science Dept. at Shahid Bahonar University of Kerman Shahid Bahonar University of Kerman
  3. 3. Group 2Service-Oriented DevelopmentAli Shakiba Lecture#1Hamid Bahrol Olum Lecture#2Arab Lecture#3Ghaini Lecture#4 Shahid Bahonar University of Kerman
  4. 4. Table of ContentsIntroduction to Service Oriented 0Reusability and its relation with SOA 1 SOA Tools 2 SOA Case Studies 3
  5. 5. ‫‪Green IT‬‬ ‫کارآیی‬ ‫کارآیی‬ ‫کارایی‬ ‫اقتصادی‬ ‫اجتماعی‬ ‫اکولوژی‬ ‫هدف ‪ Green IT‬؛ استفاده بهینه و موثر از‬ ‫منابع رایانه ای به منظور رسیدن به سه‬ ‫هدف فوق می باشد. یعنی در کنار تلش‬ ‫‪Green IT‬‬‫برای رسیدن به کارآیی اقتصادی؛ همزمان‬ ‫کارآیی محیط زیست و اجتماع نیز منظور‬ ‫شود.‬
  6. 6. Lecture # 1 Introduction to Service-OrientedShahid Bahonar University of Kerman
  7. 7. presented by: Ali Shakiba<> // I can guarantee no fast responses! Shahid Bahonar University of Kerman
  8. 8. Table of ContentsOverview of Service Oriented Architecture 1 Service Oriented Computing 2 Web Services Technology for SOA 3 SOA Lifecycle 4 SOA Design Patterns 5
  9. 9. Overview of ServiceOriented Architecture Part I Shahid Bahonar University of Kerman
  10. 10. Incremental approach to an SOA Monolithic Applications  In software engineering, a monolithic application describes a single- tiered software application in which the user interface and data access code are combined into a single program from a single platform. • From
  11. 11. Incremental approach to an SOA Intermediate stage: Individual services broken out
  12. 12. Incremental approach to an SOA Service-oriented architecture
  13. 13. An Example: Bank Teller Analogy Different types of tellers offer different services  Tellers specialized to perform only certain types of transactions (which are typically closely related)  Example partitioning: • Account Management (Opening and closing accounts) • Credits (inquiry about conditions, consulting, applying for mortgages) • Cash Register (Withdrawals, deposits, funds transfers) • Currency exchange (buy and sell foreign currencies) There may be several tellers offering the same set of services (for load balancing / failover) What happens behind the counter is not your business (bulletproof glass, iron bars) If you require a complex transaction, you may have to visit several tellers (customer as transaction coordinator)
  14. 14. It’s all about service! What do you mean? A service is a package of closely related standardized functions, which are called repeatedly in a similar fashion, and should therefore be implemented by a dedicated facility, which can be specialized to perform them.  Example: Account Management A service can be partitioned and have multiple service functions.  Example: Open new account The smallest subunits within service functions are called service primitives (also sometimes called the service).  Example: Generate next available account number
  15. 15. Characteristics To Describe A Service Service requester (“client”)  Who/which components use or need the service?  For the service requester, the provided service is most important, and not how it is implemented (principle of information and implementation hiding) Service provider (“server”)  Who/which components implement or provide the service?  is responsible for hosting the service, and ensuring the promised QoS  may charge for service usage Qualities of Service (QoS)  What are the parameters that allow to distinguish good service provisioning from bad?  Examples: Reliable, predictable execution, cost, execution time, level of privacy, other guarantees
  16. 16. Service, a picture rather a million words! Request Response
  17. 17. How Services relate
  18. 18. How services communicate
  19. 19. Logic encapsulation by service
  20. 20. Example
  21. 21. Interface (Def.) An interface constitutes the specification of a service, that is implemented by a certain component. The interface defines a contract, to which the component that implements it has to comply. Interfaces can be described using formal languages  Web Services Description Language (WSDL)  OMG/ISO Interface Definition Language (IDL) (for CORBA)  UML Object Constraint Language (OCL)  But also: Java, C++ headers, . . . Type-safe interfaces sometimes introduce tight coupling Web Services don’t force you into type-safe interfaces Different message types may be acceptable to a service
  22. 22. So you said WSDL! What is it?A WSDL document describes a web service usingthese major elements  <portType> • The operations performed by the web service  <message> • The messages used by the web service  <types> • The data types used by the web service  <binding> • The communication protocols used by the web service
  23. 23. The main structure of a WSDL Document<definitions> <types> … </types> <message> … </message> <portType> … </portType> <binding> … </binding></definitions>
  24. 24. Hey WSDL! Give me synonyms in my world! <portType> is the most important thing!  Syn. To a function library, a class or a module <message>  Syn. To parameters of a function <types>  Defines data types that web service uses! <binding>  Desc. The protocol details and message format for each port!
  25. 25. OK! I know it’s hard!A simplified part of WSDL code!<message name="getTermRequest"> <part name="term" type="xs:string"/></message><message name="getTermResponse"> <part name="value" type="xs:string"/></message><portType name="glossaryTerms"> <operation name="getTerm"> <input message="getTermRequest"/> <output message="getTermResponse"/> </operation></portType> Source:
  26. 26. Software Architecture (Def.) Software architecture encompasses the set of significant decisions about the organization of a software system  selection of the structural elements from which the system is composed, and the interfaces to these  behavior as specified in collaborations among those elements  (de/-)composition of these structural and behavioral elements into a larger system  architectural style that guides this organization • Def. from Mary Shaw at Carnegie Mellon Univ.
  27. 27. Architectural Style (Def.) An architectural style defines a family of systems in terms of a pattern of structural organization [Garland/Shaw 96] An architectural style defines:  a vocabulary of design elements • components (client, server, filter, layer, adapter…), and connector types (pipe, broadcast, queue,...)  a set of configuration rules (constraints) on how they can be combined Example styles in Software Architecture: Event-based, Repository-based, virtual machines, layered.
  28. 28. Service-Oriented Architecture (SOA) The architectural style is service-oriented if:  It is not monolithic; common blocks of functionality are broken out of the applications and are instead provided by services • A significant part of the overall functionality is implemented by services, which exist otherwise independent of the application  Design elements for an SOA are: • Components: services (can be composites), consumers, providers • Connector type: (remote) service invocations  Configuration rules for an SOA are: • No strict layering (service implementations can use other services) • No centralized control entity • Services are designed for shared use, and for use that may not even have been anticipated at design time
  29. 29. Service Orientation (Def.) Service-Orientation is an organizational principle.  A set of principles for building large systems which is not tied to any particular technology.  Examples: • Common “horizontal” services: – Logging, authentication/single-sign-on, systems management, Directory lookup of services, event notification • “Vertical” services, specific to your business domain – Product feature search service, Address management, Order Status Tracking Service, Truck/trailer tracking service  As in organizations, there is always more than one way to structure a large system
  30. 30. Quality criteria for (software) architecture Criteria to evaluate a decomposition: 1. Derived from top rank use cases (adequateness) 2. Balanced with existing assets: platform technology, frameworks, components 3. Balanced with requirements (trade-offs, performance vs. security,…) 4. Compliance with (domain-specific) industry standards and reference models (interoperability, readiness for merging) 5. Designed to make the system more resilient to future changes (20 years?) (maintainability) 6. Designed for substantial reuse, and with substantial reuse 7. Intuitively understandable (people buy-in!) (usability)
  31. 31. Forces and quality factors for software arch.
  32. 32. A Real-world SOA Project! ( A Dream )Large-scale distributed systems, such as healthcaresystems, are difficult to develop due to theircomplex and decentralized nature. The ServiceOriented Architecture facilitates the developmentof such systems by supporting modular design,application integration and interoperation, andcollaboration between independent softwaresystems. Using open standards, such as XML, SOAP,WSDL and UDDI, the Service Oriented Architecturesupports interoperability between servicesoperating on different platforms, and betweenapplications implemented in differentprogramming languages. We designed andimplemented distributed e-healthcare system thatuses the Service Oriented Architecture as a basisfor designing, implementing, deploying, invokingand managing healthcare services. The e-healthcare system that we have developedprovides support for physicians, nurses,pharmacists and other healthcare professionals, aswell as for patients and medical devices used formonitoring patients. Multi-media input and output,with text, images, speech and keyboard, make thesystem more user friendly than existing healthcaresystems.
  33. 33. Challenges and problems Technology heterogeneity of existing applications Many integration projects during the last three years  Have been tactical, not strategic (no enterprise focus)  Only solved problems for one project (e.g. for one channel)  Result: Stovepipe integrations Large organizations run 100s of apps and multiple ERPs  These systems were designed independently of each other  They overlap in functionality • They overlap in the data they manage Integration does not remove any overlap • Consolidation would be better SOA helps to address these issues
  34. 34. Benefits of SOA Design More flexibility (“business agility”)  Assumption: business process logic and business rules are no longer buried inside applications  Result: • Since they are now explicit, processes can be changed easier • Existing services can be used in different contexts • Shorter time-to market for changed processes Reduced cost of operation through consolidation  Assumption: Redundant functionality is eliminated  Result: • Fewer servers • Fewer licenses • Fewer assets to manage • Lower maintenance cost
  35. 35. Benefits of SOA Design (contd.) Higher quality  Eliminating redundancy reduces inconsistent data and behavior  More transparency  Improved system architecture – easier to understand Reduced risk, cost and complexity for development  Clean architecture  reduced cost and risk  Increased developer productivity through reuse  Projects can leverage existing services  “Black box” reuse instead of copy&paste reuse Lessen the dependencies on vendors  Service implementations can be replaced if interfaces stay the same  Services can be relocated from one platform to another  Services can even be outsourced to an external provider
  36. 36. Benefits of SOA Design (contd.) Good service design (partitioning) will outlive your middleware or implementation technology  All you have to do is to put a wrapper around it, if required  Many mainframe systems today provide many useful services that should be made available to applications elsewhere in the enterprise Commoditizing more and more parts of the IT infrastructure  Off-the-shelf infrastructure components are moving up the layers and coming closer to the application!  Due to existing industry standards and available products, developers stop building this stuff themselves: • 1990: DBMS, TP Monitors • 1992: Networking stacks • 1995: CORBA, RPC Middleware, Reliable Messaging • 1998: Naming Service, Publish and Subscribe, Event Notification • 2000: Various J2EE Services
  37. 37. Summary Precise terminology helps  to understand and handle the problem  to identify and debunk unbaked concepts Service-orientation is an architectural style SOA benefits us by  Reduced risk, cost and complexity for development  Reduced cost of operation through consolidation  business agility
  38. 38. Summary (Contd.) A Service is formally characterized by  Client  Server  QoS It’s an incremental approach to reach SOA.
  39. 39. Service Oriented Computing Part IIShahid Bahonar University of Kerman
  40. 40. SOC Definition SOC is an emerging cross-disciplinary paradigm for distributed computing that is changing the way software applications are designed, architected, delivered and consumed SOC is a new computing paradigm that utilizes services as the basic constructs to support the development of rapid, low-cost and easy composition of distributed applications even in heterogeneous environments
  41. 41. SOC vs. Object Oriented The major innovation of SOC is the move from OO paradigm into a SO one!  Object Oriented • Stateful  Service Oriented • Stateless
  42. 42. A Deeper Comparison! Methodology  OO • Application development by identifying tightly coupled classes. • Application architecture is hierarchical based on the inheritance relationships.  SO • Application development by identifying loosely coupled services and composing them into executable applications.
  43. 43. A Deeper Comparison! (contd.) Level of abstraction and cooperation  OO • Application development is often delegated to a single team responsible for the entire life cycle of the application. • Developers must have knowledge of application domain and programming.
  44. 44. A Deeper Comparison! (contd.) Level of abstraction and cooperation  SO • Development is delegated to three independent parties – application builder – service provider – service broker. • Application builders need to understand application logic and may not know how individual services are implemented. • Service providers can program but do not have to understand the applications that use their services.
  45. 45. A Deeper Comparison! (contd.) Code sharing and reuse  OO • Code reuse through inheritance of class members and through library functions. – Library functions have to be imported at compilation time and are platform dependent.  SO • Code reuse at the service level. • Services have standard interfaces and are published on Internet repository. – They are platform-independent and can be searched and remotely accessed. • Service brokerage enables systematic sharing of services.
  46. 46. A Deeper Comparison! (contd.) Dynamic binding and re-composition  OO • Associating a name to a method at runtime. – The method must have been linked to the executable code before the application is deployed.  SO • Binding a service request to a service at runtime. • The services can be discovered after the application has been deployed. – This feature allows an application to be recomposed at runtime.
  47. 47. A Deeper Comparison! (contd.) System maintenance  OO • Users need to upgrade their software regularly. – The application has to be stopped to perform the upgrading.  SO • The service code resides on service providers computers. • Services can be updated without users‘ involvement.
  48. 48. Who is using SOC? All major computer corporations, including IBM, HP, Oracle, Intel, Cisco, Sun and Microsoft have moved toward SOC. SOC is being adopted by major computer uses including  Banks • Web Banking Services  Retailers • Web Shopping Services  Airlines • Web Booking Services
  49. 49. SOC Elements Service Oriented Architecture Service Orientation Service Oriented Solution Logic Services Service Compositions Service Inventory
  50. 50. Service Composition Services can be composed of other services Services can be composed by using other services in a business logic
  51. 51. Service Inventory A service inventory is an independently standardized and governed collection of complementary services within a boundary that represents an enterprise or a meaningful segment of an enterprise
  52. 52. Service orient . {ation + ed solution logic} Service orientation:  Is a design paradigm comprised of a specific set of design principles  Specifies the creation of automation logic in the form of services Service oriented solution logic:  The application of these design principles to the design of solution logic results in service oriented solution logic
  53. 53. Model
  54. 54. Summary Service Oriented Computing is a new approach for software development; just like Object Oriented.
  55. 55. Web Services Technology for SOA Part III Shahid Bahonar University of Kerman
  56. 56. Basic Web Tech required for WS XML  eXtensible Markup Language  Documents are based on XML  XML docs are described by XML Scheme SOAP  A simple way to send docs  A way to format XML docs for transmission WSDL  Defines Implementation details about a service UDDI  Universal Description, Discovery and Integration  Store, advertise and discover services!
  57. 57. What’s a Web Service? Web services are application components Web services communicate using open protocols Web services are self-contained and self- describing Web services can be discovered using UDDI Web services can be used by other applications XML is the basis for Web services
  58. 58. How does it work? Basic WS platform is XML + HTTP Other Elements  SOAP  UDDI  WSDL
  59. 59. The future of WS WS platform is  Simple  Interoperable  Messaging … framework but it lacks  Security  Routing … but they’ll be provided as SOAP advances!
  60. 60. Why Interoperability is so important? All different major platforms can access Web using Web browsers; different platforms can interact!  An Idea! Developing Web Applications to make these platforms work together. Web Applications are simple applications run on the web.  Built around web browser standards so they can be used by any browser on any platform.
  61. 61. WS is an advanced Web Application Using WS; the web application  Publish its • Function • Message  … to the rest of the world! WS uses  XML • To code/decode data  SOAP • To transport it through open protocols
  62. 62. Two types of uses for Web Services Reusable Application Component  Offering Application Components • Like – Currency conversion – Weather report – Language translation – … Connect Existing Software  Make it possible to exchange data between different applications and platforms.
  63. 63. What is SOAP? SOAP stands for Simple Object Access Protocol SOAP is a communication protocol SOAP is for communication between applications SOAP is a format for sending messages SOAP is designed to communicate via Internet SOAP is platform independent SOAP is language independent SOAP is based on XML SOAP is simple and extensible SOAP allows you to get around firewalls
  64. 64. WSDL (Reminder) WSDL stands for Web Services Description Language WSDL is written in XML WSDL is an XML document WSDL is used to describe Web services WSDL is also used to locate Web services
  65. 65. What’s UDDI? UDDI stands for Universal Description, Discovery and Integration UDDI is a directory for storing information about web services UDDI is a directory of web service interfaces described by WSDL UDDI communicates via SOAP
  66. 66. Summary WS is a way for converting applications into Web Applications. WS uses XML to send messages between applications. WS = exporting a function from an application. WSDL is an XML based language for describing services. SOAP is an XML based protocol for exchanging data through HTTP.
  67. 67. SOA Lifecycle Part IVShahid Bahonar University of Kerman
  68. 68. SOA Lifecycle Logical steps to implement an SOA system. 1. Model 2. Assemble 3. Deploy 4. Manage
  69. 69. Model Phase Modeling the current business processes Optimizing Business processes for agility and more performance Modeling the result of optimization for target business processes Simulating the models and evaluating possible outcomes  Helps in agility of the enterprise
  70. 70. Assemble Phase It’s splited into 3 sub-phases  Service Design  Service Building  Service Integration In this phase, in fact, Services are implemented; then they are assembled  Means discovered … and composed to implement the bussiness processes that are tested for requirements.  Functional or Non-functional
  71. 71. Deploy Phase The assembled business processes are deployed on the operating run-time environment.
  72. 72. What’s a run-time? After Assemble phase; the BPs are ready to be deployed into a run-time.  It should support the execution of Dynamic BPs  It should provide open-standards based execution environment to allow services to readily invoke other services.
  73. 73. Execution Environment 3 basic must support features:  Protocol translation between various service invocations  Routing between appropriate service providers  Mediation to provide features like security, auditing, logging, and so on
  74. 74. Manage Phase The services and the business processes that are executing on the run time are monitored and analyzed to ensure their smooth operations. IT metrics like security, performance, and availability are also measured. The services and business processes are further monitored to ensure compatibility with the business metrics and service-level agreements (SLA) that are supposed to be met.
  75. 75. Manage Phase It can be broken out into 4 sub-categories  Manage Business Processes  Manage Service Layer  Manage Transaction performance  Manage Service Security
  76. 76. Design Patterns for SOA Part V Shahid Bahonar University of Kerman
  77. 77. SOA Scenarios IBM has found 8 common design patterns for SOA  It names them as SOA Scenarios They can be classified into 5 classes according to their entry points  People • Enabling human and process interaction  Process • Enabling and achieving greater efficiency and effectiveness through business model innovation  Information • Delivering trusted information to enable business processes  Connectivity • Achieving an on-demand flexibility by connecting software systems and services
  78. 78. SOA Scenarios (contd.)  Reuse • Minimizing complexity of SOA adoption and implementation by fostering reuse of high-value enterprise assets Each scenario is further broken down into realizations  They are specific development tasks design to solve a particular problem Scenarios can be categorized into 2 parts  Functional  Supporting
  79. 79. SOA Scenarios (contd.) The functional scenarios map directly to one or more SOA entry points. The supporting scenarios cut across all the entry points.
  80. 80. Functional Scenarios Service Creation Service Connectivity Interaction and Collaboration Services Business Process Management Information as a Service
  81. 81. Supporting Scenarios SOA Design SOA Governance SOA Security and Management
  82. 82. Service Creation Creating flexible, service-based business applications. A new service-oriented application exposes business behavior as a service and also reuses business logic, which is exposed as a service. The scenario also provides guidelines on how to provision the services as soon as they are created. The identification and realization of services are the first steps in implementing the vision of a set of optimized business processes
  83. 83. Service Creation (contd.) Services can be identified essentially from three main sources  Existing assets • Services that are identified from high-value business functions already deployed in existing systems – for example, legacy or packaged applications  External service provider • Services that are provided by an external vendor, most likely a vendor who provides services in a specific area
  84. 84. Service Creation (contd.) New services identified using a "top-down" approach • Services that are identified through a top-down decomposition technique – process decomposition » These services fill the gaps that are not addressed by the first two sources; they are new services that need to be implemented from scratch
  85. 85. Service Connectivity Builds on the Service Creation scenario  According to which services have been identified, designed, and built, and focuses on the underlying connectivity used to support a business-centric SOA. This scenario enables users to have the flexibility of independently changing the service consumer or the service consumer in a manner that is nondisruptive to either.
  86. 86. Service Connectivity (contd.) The scenario helps in identifying the characteristics  Such as routing, transformation, mediation of an Enterprise Service Bus (ESB) that may be used to provide decoupled connectivity between service providers and consumers. The scenario also provides guidance on how to create a logical as well as physical realization of a service gateway pattern  That provides mediation capabilities to enable transparent interoperations across mismatched and evolving systems, both at the protocol and interface level. The service gateway pattern also provides guidance on how to enforce security on service invocations.
  87. 87. Interaction and Collaboration Services Presents a service or set of services to a human user through a browser, PC, mobile device, voice response system, etc. It focuses on usability issues  such as offering single sign-on to multiple systems and providing role-based portals to consolidate access to information and applications within the enterprise and between enterprises. The key drivers for this scenario are improving productivity of the people who use the system and consumability of the applications and content that make up the system.  The content can be personalized in the aggregated portal page based on the user role.
  88. 88. Business Process Management Assists in the optimization and automation of business processes and aligns an organizations core assets  people, process, information, and technology … in order to create a single integrated view, real-time intelligence, and appropriate business and IT metrics that enable operational efficiency. This scenario concentrates mainly on process modeling and simulation, process integration, process monitoring (also called business activity monitoring, or BAM), process- oriented content aggregation, business rules management, and effective collaboration between people, process, and technology. Enterprises that are process-centric can gain from using this scenario in their SOA transformation.
  89. 89. Information as a Service Makes information usable in an SOA by expanding the business value of data. This scenario is especially applicable when an enterprise:  Has too much information but is not sure of its business relevance  Stores multiple versions of information, making it difficult to determine which information source to use  Does not rigorously enforce data quality in its store(s) of information  Maintains disconnected silos of information that may duplicate each other or contain different sets of data that cannot be reconciled
  90. 90. Information as a Service (contd.) The crux of this scenario is the virtualization and centralization of information to create a set of consistent, reliable data.  That virtual single version of data can then be made available as a service to the entire SOA system, which can use it in a standardized way for business process enablement.
  91. 91. SOA Design A cross-cutting scenario that focuses on methodologies for modeling, design, and architecture of an SOA-based software development. This scenario aligns the modeling of business design and IT solution design through a set of roles, methods, and artifacts.  Once this is accomplished, business processes can be optimized and realized as services so that the services are aligned with the business and offer true business value.
  92. 92. SOA Governance A cross-cutting scenario focusing on a decision- making and enforcement process to oversee SOA planning and execution. It is based on a decision rights and management framework that includes the establishment of chains of authority, roles, controls, and so forth, for the four phases of the SOA life cycle. This scenario also focuses on defining high-value business services and measuring their effectiveness at run time.
  93. 93. SOA Security and Management A cross-cutting scenario focusing on management of services at run time and ensuring secure external consumer access to high-value business services. The management of services focuses on automating and simplifying IT processes, managing service levels of services and applications, and predicting and managing change across interdependent and composite services.
  94. 94. SOA Security and Management (contd.) Service security focuses on managing the federated identity and access control across services, securing access to services and applications, and consistently enforcing security policies for services.
  95. 95. SOA scenarios and their relationships
  96. 96. IBM recommends a process for SOA Scenario usage
  97. 97. Summary The SOA scenarios represent a set of generic business scenarios in which SOA is being used in typical customer engagements. The SOA scenarios are representative of common scenarios of use of IBM products and solutions that are used in SOA engagements to solve real- world problems.
  98. 98. Lecture # 2 Reusability and its relation with SOAShahid Bahonar University of Kerman
  99. 99. presented by: Hamid Bahrol OlumShahid Bahonar University of Kerman
  100. 100. Table of Contents ************ 0 ************ 1 ***************** 2 ************** 3
  101. 101. Lecture # 3 SOA ToolsShahid Bahonar University of Kerman
  102. 102. presented by: ArabShahid Bahonar University of Kerman
  103. 103. Table of Contents ************ 0 ************ 1 ***************** 2 ************** 3
  104. 104. Lecture # 4 SOA Case StudiesShahid Bahonar University of Kerman
  105. 105. presented by: GhainiShahid Bahonar University of Kerman
  106. 106. Table of Contents ************ 0 ************ 1 ***************** 2 ************** 3
  107. 107. References Part VIShahid Bahonar University of Kerman
  108. 108. Refrence1. SOA: Principles of Service Design; Thomas Erl; Prentice-Hall2. Introduction to Service oriented computing; W.T.Tsai, Yinong Chen3. Service oriented computing: Key concepts and principles; Michael N. Huhns, Munindar P.Singh4. Introduction to Web Services (WS) & Service- Oriented Architecture (SOA); Eric Newcomer; Presented at SOA, MDA, and Web Services Workshop: Integrating the Enterprise, and Beyond, 2006 by OMG
  109. 109. Reference (contd.)5. Architecture in practice; 7 parts; by Tilak Mitra; at IBM developerWorks.6. W3School at
  110. 110. Thanks & Readyfor Questions and NO ANSWERS! Shahid Bahonar University of Kerman