180 likes | 335 Views
SOA: Service Oriented Architecture or Second-hand Old Abbreviation. Rune Schumann, Senior Consultant. Agenda. What is an SOA, and what is the key characteristics? What the news? SOA and technology How to migrate to a SOA, and critical success factors SOA and methods
E N D
SOA:Service Oriented ArchitectureorSecond-hand Old Abbreviation Rune Schumann, Senior Consultant
Agenda • What is an SOA, and what is the key characteristics? • What the news? • SOA and technology • How to migrate to a SOA, and critical success factors • SOA and methods • The answer of the title...
What is an Service Oriented Architecture Service-oriented architectures (SOAs) are an approach to enterprise business systems and applications that considers software resources as services available and discoverable on a network. (Jason Bloomberg, Zapthink) Service Registry Publish Find Service Provider Service Consumer Bind
What are the key characteristics of an SOA • All (business) functions must be defined as services • Consist of non-published low-level functions • All services must be independent • Black box • The interfaces must be invokable • Location transparent
What’s the news? • We have heard this things before… • Relational DB, Object oriented Programming, CORBA, COM, … • Yet another implementation of RM-ODP (Reference Model Open Distributed Systems) • Why hasn’t this saved the IT world? • To a large extend use of proprietary standards with high degrees of technical dependencies • The proposed solutions had a technical and functional approach
Why will it succeed (this time…) • No silver bullet (sorry to disappoint you…) • But there is hope: • XML, SOAP and WebServices has made it acceptable to formalize exchange of information • Layering discussions now concerns content, information, structures, processing, availability, … • Makes premises to survey how the business is actually working • Mapping the business processes to the IT architecture
SOA Logistics Invoice Order What is the mission of SOA • Act as a glue between IT monoliths in an enterprise • Typical candidate is an enterprise with a heterogeneous IT architecture • Glue together scattered business processes
SOA and technology • SOA is technology agnostic • But certain characteristics must be fullfilled: • An adapter layer • Some kind of service broker • Some kind of mechanism to provide flow controll Flow layer Broker layer Adapter layer Legacy 1 Legacy 2 Legacy 3 Legacy 3
SOA in a homogenous J2EE environment… SO Awkward..?... • Can be quite easily realized • A handful of GoF-patterns: • Factory, Proxy, Service Locator, Business Delegate and a Service Façade… • The client interacting through a Proxy … • Fine, and so… • What about my good old salary system? • Be aware of what you are introducing where!
SOA is about • Changing the way application systems work by simply altering the components that are already in use, rather than buying or coding new components or whole systems from scratch • Leveraging existing IT investments
How to migrate to an SOA • Get an overview of the relevant business processes in the enterprise • Create a broad architectural roadmap that provides a high-level direction for the enterprise architecture of the company based upon clear business requirements • Start with a pilot project involving a suitable business process • Continue to identify high “bang for the buck” projects in the enterprise that are suitable for a service-oriented solution • Repeat step four as necessary
Critical success factors to realize a SOA • A number of more technical issues. • The services are truly independent • The services have the correct granularity level • The coordination of services does not result in inconsistence • The needed security contexts has been taken care of • The services need for distributed transactions has been taken care of • The services can be managed • But these are the easiest ones…
Critical success factors to realize a SOA • Actors starting with technology are doomed to loose • Commitment from top-management is of utterly importance • Vital to establish a proper understanding of the involved business processes • SOA projects are much more dependant on the business requirements than traditional IT projects
SOA and methods • In a traditional RUP project, the activities of the Domain Expert, Business Designer, and the Business Process Analyst are mostly limited to the inception phase • In a SOA project, they need to be much more involved throughout the whole project • Critical to fulfill the main purpose of a SOA: • Development of a given corporations business processes based on a set of reusable core services
When not to use SOA • Homogenous IT architectures • Real-time systems • Companies with stable IT architecture and business processes • Low coupling is not an issue
Bouvet og SOA • Bouvet have been working with Service Oriented Architectures since the mid 90’s. • Bouvet has been selected as Enterprise Architect Partner for several of Norway’s largest companies with the object of migrating to SOA. • We have one of the most competent teams in Norway with competence from Business Architecture/processes through integration to system architecture. • Some of the references includes Statoil, Statkraft and ICA.
SOA = Second-hand Old Abbreviation? • Yes, to a certain extend! • Most of the concepts have been tried before • But a key difference is • The focus on what the enterprise is doing for a living!
References • Michael Stevens; Service-Oriented Architecture Introduction, Part 1 & Part 2 • Michael Stevens; Multi-Grained Services • Kishore Channabasavaiah, Kerrie Holley, Edward M. Tuggle, Jr.; Migrating to a service-oriented architecture, Part 1 & Part 2 • Jason Bloomberg; Service-Oriented Architecture: Why and How? • Walter Hurst; Web Services Journal, Feb 2003: Critical decisions for service-oriented architecture: four keys to a common interoperable foundation • Zapthink site: http://www.zapthink.com