Introduction : So what is it all about these buzz words like SOA, ESA? The first time I heard of these, they made me feel outdated. So I decided to find out more about what it is all about and have summed up my learning as under. The following article briefly touches upon the Service oriented Architecture and how it relates to SAP’s vision of transforming the Enterprise business logic into a set of service oriented components. The intended audience is basically the beginners who want to know about SOA and ESA, developers who want to scale up their skills to “possibly” the new or may I say the next architectural and programming paradigm for SAP. The article has been summed up under the following sections. - Basic Terminology of Software Architectures - SOA definition – why , what , when and how - ESA and its relation to SOA - Evolution of SAP architecture - What does this change mean for developers Some common terms to be familiar with before we head into the SOA paradigm. Software architecture : The software architecture discipline is centered on the idea of reducing complexity through abstraction and separation of concerns. Some examples of Software architecture include the Client Server model, the distributed computing model. Client server: It is network architecture which separates a client (often an application that uses a graphical user interface) from a server. Each instance of the client software can send requests to a server. Specific Types of servers include application servers, file servers, terminal servers, and mail servers. While their purpose varies somewhat, the basic architecture remains the same. Three-Tier Architecture:Three-tier is a client-server architecture in which the user interface, functional process logic ("business rules"), data storage and data access are developed and maintained as independent modules, most often on separate platforms. The 3-Tier architecture has the following 3-tiers. 1. Presentation Tier 2. Application Tier /Logic Tier/Business Logic Tier 3. Data Tier Loose coupling : This term implies that the interacting software components minimize their in-built knowledge of each other: they discover the information they need at the time they need it. For example, having learned about a service's existence, a client can discover its capabilities, its policies, its location, its interfaces and its supported protocols. Once it has this knowledge, the client can access the service using any mutually acceptable protocol. For example the WWW is a loosely coupled universal system wherein a user type in the IP address in the browser not knowing about the server etc. During runtime the specific address is found out and the respective file is fetched from the server and displayed on user's PC. SOA definition – What, why and when : The What : SOA is a design for linking computational resources (principally, applications and data) on demand to achieve the desired results for service consumers (which can be end users or other services). It is not a new concept and has been existence from long before in the form of web services using technologies like DCOM and CORBA. SOA emphasizes the implementation of components as modular services that can be discovered and used by clients. I see this similarity here where we search for existing Function Modules from the repository which can be reused in custom programs, the difference being that as a Service its functionality is at a more abstract level and the interface mapping is more dynamic. Services communicate with their clients by exchanging messages which are platform independent. Thus the services are defined by the messages they can accept and the responses they can give, which is why XML as a standard platform independent way of exchanging messages becomes all the more important. Services generally have the following characteristics: 1. Services may be individually useful, or they can be integrated—composed—to provide higher-level services. 2. Services can participate in a workflow, where the order in which messages are sent and received affects the outcome of the operations performed by a service 3. Services may be completely self-contained, or they may depend on the availability of other services, or on the existence of a resource such as a database. 4. Services advertise details such as their capabilities, interfaces, policies, and supported communications protocols. Implementation details such as programming language and hosting platform are of no concern to clients, and are not revealed. 
Source: An overview of service-oriented architecture, Web services and grid computing by Latha Srinivasan and Jem Treadwell, HP Why SOA? - Promotes re-use of existing functionality. - Supports a distributed model of computing - Enable scalability and reuse of components of across a wider development community - Provides a uniform way of handling the functionality especially true in a large business environment. How programming in SOA is different from Object Oriented programming? A service-oriented approach gives the developers and architects an easy way to integrate systems. They are more robust, scalable, easily maintained, and they are much easier for designers to conceptualise. However the complexity of the system landscape is more often influenced by the design rather than the architecture chosen keeping in view the number of systems and technology at hand. And because this kind of architecture is loosely coupled, interacting through a common set of standards, the robustness and scalability comes with a cost. Yes, you might have guessed it.. It is the system performance. As I understand that any loosely coupled architecture can never be as performance intensive as a tightly coupled architecture in spite of the many optimisations that are possible. If we take the case of programming paradigms we had the three below set dominating the commercial market. • Procedural Programming • Object Oriented Programming • Service Oriented programming I view these as sets in which the each of them is contained within the other with increasing levels of abstraction. Just to give an example we still use procedural way of programming within each of the methods of a class. Similarly SOA will still need OO way of programming but following a certain set of constraints. These are the constraints that make the discovery and invocation of services dynamic and hence more robust. Whereas in a pure object oriented way of programming, the reusable component’s interface details need to be known prior to it being reused. If implemented in the Enterprise Business model a further restriction of SOA would happen such that security and other enterprise wide issues are taken care of to remove it from the Web services way of implementing the SOA. When SOA? SOA is already implemented mostly as Web services. Web services standards have catalysed the adoption of standards-based SOA. Early Web services standards - SOAP and HTTP - provide ubiquitous protocols suitable for SOA. Lot of activity has stirred up with incorporation of SOA into the enterprise business systems which started of in 2004. We are currently at stage where this concept is in the stages of it being realised. This drives us to dwell into what ESA or ESOA is (which has been termed by SAP as it next level architecture). ESA and its relation to SOA Service-oriented architecture operates within the semantic realm of IT, but not necessarily that of business. SOA can support integration and consolidation activities within complex enterprise systems, but SOA does not specify or provide a methodology or framework for documenting capabilities or services. Enterprise Service oriented Architecture is the adoption of SOA at an enterprise level. It breaks the traditional Client server application oriented architecture. What Enterprise oriented architecture has done is to break down each of the core business functionality into services. This paves the way for building reusable components (services) using the existing service repository and hence promoting a common inter operatable platform for service reuse across disparate systems not only within but also across the systems spaning organisations and its partners. To summarise ESA = SOA + Enterprise content or in other words ESA is an instantiation of SOA at ERP level. Why ESA? As SAP puts it “ESA provides business value by supporting the cycle of innovation and standardization in a single environment by defining software architecture that : Enhances productivity through standardization and keeping control of business processes, (e.g. out-tasking of non-differentiating tasks); Drives differentiation by designing new business processes based upon the existing infrastructure and leveraging existing functionality, and Provides high flexibility for managing and adapting processes in time, to keep up with the pace of business change.” Ultimately it all boils down to terms like ROI (Return on Investment) and TCO(Total Cost of Ownership) for each of the companies. As SAP says ESA will enable companies to build, change, and expand business processes at a lower cost. Extend existing applications and Innovate processes to keep up with accelerated business change. When ESA? ESA adoption is not a one time project implementation but it’s rather a start of the journey. ESA is not technology driven but more of process driven This is not just about cost-cutting IT budgets. It's also about creating a more flexible architecture for business. Different approaches may be taken in implementing it and the following diagram gives a brief overview on how organisations can proceed with their ESA adoption 
Source: Getting Started with Enterprise Services Architecture: Beyond Integrating Systems to Enabling Growth and Innovation - by Ravi Swaminath Evolution of SAP architecture R/2 was implemented atop mainframe databases like DB/2 , Adabas, and IMS The client server architecture was replaced by the 3 tier architecture. R/3 system using a multi-tiered Client/Server architecture, with data storage on a database server running some relational database, application code, written in their ABAP/4 language, running on a set of application servers. This was a set of application which interacted with each other based on the business rules derived by industry experts 
Source: Balancing ESA adoption with SOA Best practices by Scott Campbell 
Source: SAP AG 2005-06 SAP R/3 through version 4.6c consisted of various applications on top of SAP Basis, SAP's set of middleware programs and tools. SAP R/3 Enterprise (2002), all applications were built on top of the SAP Web Application Server. Extension sets were used to deliver new features and kept the core as stable as possible. The Web Application Server contained all the capabilities of SAP Basis. mySAP ERP – Ist Edition (2003) : It bundled previously separate products, including SAP R/3 Enterprise, SAP Strategic Enterprise Management (SEM) and extension sets. The SAP Web Application Server was wrapped into NetWeaver, which was also introduced in 2003. A complete architecture change took place with the introduction of mySAP ERP edition 2004. R/3 Enterprise was replaced with the introduction of ERP Central Component (SAP ECC). The SAP Business Warehouse, SAP Strategic Enterprise Management and Internet Transaction Server were also merged into SAP ECC, allowing users to run them under one instance. Architectural changes were also made to support enterprise services architecture to transition customers to a services-oriented architecture. SAP’s vision and the brief components of the Discovery system SAP has come out with the Discovery system which helps organisations build a Roadmap for converting their architecture to ESA. It is not just an upgrade as ESA is neither a product nor a tool. It is neither being forced upon but has been clearly stated that ESA is the future road map. The below diagram briefly summarises the vision of how architecture of an organisation should/would be, which is to be easily scalable and be robust thus enabling change and integration. 
One central ESR: • Serves as a common foundation across multiple systems for both internal and external integration • Partner community contributes into ESR.(Enterprise service repository) SAP Discovery System: With SAP Discovery System for enterprise SOA, you get a complete, fully documented system with standard SAP software components More information at ESA Discovery What ESA paradigm means for developers 1. Learning technologies like WSDL, XML and IDLs. 2. Familiarize with the existing service repository 3. Setting up of development standards to create and enforce the following • Naming conventions • Message structure • Service documentation • Interoperability 4. Better search mechanisms for discovering existing services which have already been defined and implemented across the organisation. 5. Manage the deployment of services centrally Food for Thought: Although service based architecture in Enterprise systems seem to satisfy a more flexible model of computing, does it or can it come with more set of problems viz a viz performance, user response time, confusion between similar set of services. Can an agent based Architecture with a set of mobile agents performing the services help overcome the drawbacks. An Agent can be an independent entity performing a set of tasks for example an agent for handling purchase orders which can replicate and travel across network. Do you think the agent based architecture in its true sense (mobile agents across the network) will be the next Architectural paradigm for the Enterprise? With these few questions to ponder I will conclude my topic here. Thanks References: 1.An overview of service-oriented architecture, Web services and grid computing by Latha Srinivasan an... 2. Enterprise SOA made easy and A complete learning environment for Enterprise at SAPinsider 3. Scott Campbell @ SOA WORLD MAGAZINE - Balancing ESA adoption with SOA best practices 4. www.wikipedia.org 5. Getting Started with Enterprise Services Architecture: Beyond Integrating Systems to Enabling Growth and Innovation - by Ravi Swaminath at SAPinsideronline
Source: An overview of service-oriented architecture, Web services and grid computing by Latha Srinivasan and Jem Treadwell, HP Why SOA? - Promotes re-use of existing functionality. - Supports a distributed model of computing - Enable scalability and reuse of components of across a wider development community - Provides a uniform way of handling the functionality especially true in a large business environment. How programming in SOA is different from Object Oriented programming? A service-oriented approach gives the developers and architects an easy way to integrate systems. They are more robust, scalable, easily maintained, and they are much easier for designers to conceptualise. However the complexity of the system landscape is more often influenced by the design rather than the architecture chosen keeping in view the number of systems and technology at hand. And because this kind of architecture is loosely coupled, interacting through a common set of standards, the robustness and scalability comes with a cost. Yes, you might have guessed it.. It is the system performance. As I understand that any loosely coupled architecture can never be as performance intensive as a tightly coupled architecture in spite of the many optimisations that are possible. If we take the case of programming paradigms we had the three below set dominating the commercial market. • Procedural Programming • Object Oriented Programming • Service Oriented programming I view these as sets in which the each of them is contained within the other with increasing levels of abstraction. Just to give an example we still use procedural way of programming within each of the methods of a class. Similarly SOA will still need OO way of programming but following a certain set of constraints. These are the constraints that make the discovery and invocation of services dynamic and hence more robust. Whereas in a pure object oriented way of programming, the reusable component’s interface details need to be known prior to it being reused. If implemented in the Enterprise Business model a further restriction of SOA would happen such that security and other enterprise wide issues are taken care of to remove it from the Web services way of implementing the SOA. When SOA? SOA is already implemented mostly as Web services. Web services standards have catalysed the adoption of standards-based SOA. Early Web services standards - SOAP and HTTP - provide ubiquitous protocols suitable for SOA. Lot of activity has stirred up with incorporation of SOA into the enterprise business systems which started of in 2004. We are currently at stage where this concept is in the stages of it being realised. This drives us to dwell into what ESA or ESOA is (which has been termed by SAP as it next level architecture). ESA and its relation to SOA Service-oriented architecture operates within the semantic realm of IT, but not necessarily that of business. SOA can support integration and consolidation activities within complex enterprise systems, but SOA does not specify or provide a methodology or framework for documenting capabilities or services. Enterprise Service oriented Architecture is the adoption of SOA at an enterprise level. It breaks the traditional Client server application oriented architecture. What Enterprise oriented architecture has done is to break down each of the core business functionality into services. This paves the way for building reusable components (services) using the existing service repository and hence promoting a common inter operatable platform for service reuse across disparate systems not only within but also across the systems spaning organisations and its partners. To summarise ESA = SOA + Enterprise content or in other words ESA is an instantiation of SOA at ERP level. Why ESA? As SAP puts it “ESA provides business value by supporting the cycle of innovation and standardization in a single environment by defining software architecture that : Enhances productivity through standardization and keeping control of business processes, (e.g. out-tasking of non-differentiating tasks); Drives differentiation by designing new business processes based upon the existing infrastructure and leveraging existing functionality, and Provides high flexibility for managing and adapting processes in time, to keep up with the pace of business change.” Ultimately it all boils down to terms like ROI (Return on Investment) and TCO(Total Cost of Ownership) for each of the companies. As SAP says ESA will enable companies to build, change, and expand business processes at a lower cost. Extend existing applications and Innovate processes to keep up with accelerated business change. When ESA? ESA adoption is not a one time project implementation but it’s rather a start of the journey. ESA is not technology driven but more of process driven This is not just about cost-cutting IT budgets. It's also about creating a more flexible architecture for business. Different approaches may be taken in implementing it and the following diagram gives a brief overview on how organisations can proceed with their ESA adoption Source: Getting Started with Enterprise Services Architecture: Beyond Integrating Systems to Enabling Growth and Innovation - by Ravi Swaminath Evolution of SAP architecture R/2 was implemented atop mainframe databases like DB/2 , Adabas, and IMS The client server architecture was replaced by the 3 tier architecture. R/3 system using a multi-tiered Client/Server architecture, with data storage on a database server running some relational database, application code, written in their ABAP/4 language, running on a set of application servers. This was a set of application which interacted with each other based on the business rules derived by industry experts Source: Balancing ESA adoption with SOA Best practices by Scott Campbell Source: SAP AG 2005-06 SAP R/3 through version 4.6c consisted of various applications on top of SAP Basis, SAP's set of middleware programs and tools. SAP R/3 Enterprise (2002), all applications were built on top of the SAP Web Application Server. Extension sets were used to deliver new features and kept the core as stable as possible. The Web Application Server contained all the capabilities of SAP Basis. mySAP ERP – Ist Edition (2003) : It bundled previously separate products, including SAP R/3 Enterprise, SAP Strategic Enterprise Management (SEM) and extension sets. The SAP Web Application Server was wrapped into NetWeaver, which was also introduced in 2003. A complete architecture change took place with the introduction of mySAP ERP edition 2004. R/3 Enterprise was replaced with the introduction of ERP Central Component (SAP ECC). The SAP Business Warehouse, SAP Strategic Enterprise Management and Internet Transaction Server were also merged into SAP ECC, allowing users to run them under one instance. Architectural changes were also made to support enterprise services architecture to transition customers to a services-oriented architecture. SAP’s vision and the brief components of the Discovery system SAP has come out with the Discovery system which helps organisations build a Roadmap for converting their architecture to ESA. It is not just an upgrade as ESA is neither a product nor a tool. It is neither being forced upon but has been clearly stated that ESA is the future road map. The below diagram briefly summarises the vision of how architecture of an organisation should/would be, which is to be easily scalable and be robust thus enabling change and integration. One central ESR: • Serves as a common foundation across multiple systems for both internal and external integration • Partner community contributes into ESR.(Enterprise service repository) SAP Discovery System: With SAP Discovery System for enterprise SOA, you get a complete, fully documented system with standard SAP software components More information at ESA Discovery What ESA paradigm means for developers 1. Learning technologies like WSDL, XML and IDLs. 2. Familiarize with the existing service repository 3. Setting up of development standards to create and enforce the following • Naming conventions • Message structure • Service documentation • Interoperability 4. Better search mechanisms for discovering existing services which have already been defined and implemented across the organisation. 5. Manage the deployment of services centrally Food for Thought: Although service based architecture in Enterprise systems seem to satisfy a more flexible model of computing, does it or can it come with more set of problems viz a viz performance, user response time, confusion between similar set of services. Can an agent based Architecture with a set of mobile agents performing the services help overcome the drawbacks. An Agent can be an independent entity performing a set of tasks for example an agent for handling purchase orders which can replicate and travel across network. Do you think the agent based architecture in its true sense (mobile agents across the network) will be the next Architectural paradigm for the Enterprise? With these few questions to ponder I will conclude my topic here. Thanks References: 1.An overview of service-oriented architecture, Web services and grid computing by Latha Srinivasan an... 2. Enterprise SOA made easy and A complete learning environment for Enterprise at SAPinsider 3. Scott Campbell @ SOA WORLD MAGAZINE - Balancing ESA adoption with SOA best practices 4. www.wikipedia.org 5. Getting Started with Enterprise Services Architecture: Beyond Integrating Systems to Enabling Growth and Innovation - by Ravi Swaminath at SAPinsideronline
10 Comments
