Service Oriented Architecture (SOA)
{"Image DocumentName": "Service Oriented Architecture (SOA)", "Image ImageDescription": "What is SOA? Title. Month Year. Service Oriented Architecture (SOA) Is a computer systems architectural style for creating and using business processes, packaged as services, throughout their lifecycle. SOA also defines and provisions the IT infrastructure to allow different applications to exchange data and participate in business processes. These functions are loosely coupled with the operating systems and programming languages underlying the applications. Let\u2019s start first with a definition of SOA \u2013 Service Oriented Architecture. Long before industry coined the phrase, Documentum was founded on service orientation. Let\u2019s step back and look at the concept of service oriented architecture as defined in today\u2019s vernacular. (see slide definition and Notes on Value of SOA below). An architecture style for building business applications as a set of loosely coupled interactive components or services, orchestrated to deliver a well-defined level of service by linking together business processes. There are many different definitions of SOA \u2013much like the version here, But they all contain similar concepts. Architecture. Loose coupling. Services and service levels. Business process. It is also useful to define what SOA is not: A product. Just about Web Services. Just another transport. The SOA concept of loosely coupled components addresses these concerns. A simple way to think of these component is to drawn an analogy to Lego blocks, a child s toy that has snap together pieces. This provides ultimate flexibility \u2013 one day a child can build a car, add specialized pieces like wheels and a steering wheel, the next day he can remove the wheels, pop on a sail and he has a boat. SOA leverages the loosely coupled, interoperable nature of Web Services to enable today\u2019s heterogeneous collections of applications and systems to provide flexible, resilient IT functionality that meets ever-changing business requirements. The magic in SOA comes from the loosely couple components \u2013 lets examine that concept next. In SOA \u2013 linear programs are decomposed into loosely couple reusable services \u2013 that can be assembled dynamically. Component characteristics. Not dependant, changing one will not have a direct affect on any others. Not dedicated to each other, not hard wired together and find each other when needed through a registry. Link dynamically - many on the network accessing each other when needed. SOA uses as software building blocks. Each component offers a small range of simple services to other components. <click> As an example: Before SOA. Imagine Sam in Finance builds a loan program that includes a credit check on the customer \u2013 Jill in purchasing builds a purchase program that also includes a credit check on the supplier \u2013 Duplicate effort in coding, but worse \u2013 in the credit check process changes, now you have to locate all the programs that might include the process and rewrite the code. With SOA. Now, instead of hard-coding a solution, applications can be assembled. The credit check is one service that both applications can call \u2013 to make an enterprise wide change, you just need to change that one service. Imagine in this example that the company completely changes its approval process \u2013 due to a compliance issue or regulation requirement. Now is a simple process of updating one service and the entire corporation has access to the updated process. Source:  8.", "Image XResolution": "37", "Image YResolution": "37", "Image ResolutionUnit": "Pixels/Centimeter", "Image Software": "SlidePlayer", "Image YCbCrPositioning": "Centered"}