This slide shows several of the most common buzzwords and terms used when talking about SOA. There is a lot of hype about SOA, at the same time SOA cannot be dismissed as a hype because there are a number of trends and concrete implementations emerging in the industry that shows that SOA is here to stay as an IT architecture and business initiative. Talk about: - SOA is a Hype and a Reality - It is getting harder to separate the two - SOA brings together a number of different promises (See The Promise of SOA slide) - SOA has many perspectives. - Different people appreciate different perspectives of SOA. Therefore some of these buzzwords take on different lives depending on the perspective of the audience member.
These are analyst quotes talking about SOA. Talk about how different analysts focus on SOA. Highlighted words indicate the different emphasis on SOA from each analyst.
This is a set of definitions for SOA. There is not “The” definition for SOA because there are different definitions in the industry. Instead focus on the common themes in those definitions. The highlighted words in the above definitions show how different definitions focus on different perspectices and aspects of what SOA brings to the table. The first bullet is from the Sun SOA Platform Vision whitepaper definies SOA as: SOA is an architectural style that emphasizes loosely coupled , coarse-grained , shareable , secure, network based services to enable business flexibility in an interoperable technology agnostic manner.
This picture is not intended to suggest that all architectures are accidental. What has been researched and determined is that Silos emerge out of business needs and the traditional ways of building applications. However, as businesses change, merge, collaborate, we integrate the silos in the most sensible and pragmatic way possible for the given problem, scenario and business need. What this results in is an emergence of accidental architecture as relative to integration of Silo systems. While each Silo can be a well architected system in iteself, the overall architecture of the enterprise becomes accidental or forced by the nature of business and market conditions. The bullet points highlight some of the drawbacks of such architecture. Also note that the term “Accidental Architecture” originates from the University of Kent paper as quoted above. Recently, more attribution has been given to Sonic Software because they have been using this term as well.
These are some of the promises of SOA. Things to note: 1. Interoperability is the key promise of SOA. However, it is complex and can mean different things because there are different levels of interoperability. 2. Emphasise: Wrap and Reuse; lots of customer have legacy apps that are performant and have huge value already locked in. Instead of replacing them, it is more pragmatic to reuse by wrapping a services layer on top of the legacy layer. 3. Talk about the importance of Standards in SOA. 4. Key Key Key point: SOA is not just technology or architecture or products. We will get to that later. However, the alignment between IT and business units is a key factor to make SOA successful in any organization.
This is a conceptual model of SOA. Note that this is very similar to the CORBA, WS-I Basic Profile model, etc. There is inherently nothing new in SOA in terms of a conceptual model. We talk about the fact that: 1. There are service providers who provide services 2. Services are described in a standard manner 3. Services and the descriptions are registered in some registry 4. Service consumers will search & find the services via the registry 4. Service consumers will bind and invoke the services dynamically
SOA is a style of design, deployment, and management of both applications and software infrastructure in which: - Applications are organized into network accessible business services - Service interface definitions are first-class development artifacts - Quality of service (QoS) characteristics are explicitly identified and specified Software infrastructure takes active responsibility for managing service access, execution, and QoS. - Services and their metadata are cataloged in a repository and discoverable - Protocols within the architecture are predominantly, but not exclusively, based on industry standards Derived from: ‘Your Strategic SOA Platform Vision’ March 29, 2005 by Randy Heffner, Forrester Research. See the Sun SOA Platform Vision whitepaper for more details.
Layering is one of the key big rules of SOA. It is covered in the SOA Big Rules section also. However, this picture highlights the logical abstractions of layering. - Resource Layer abstracts the resouces such as data, legacy systems, etc. - Service Layer abstracts the traditional applications, application services, components, applicaition logic and services - Process layer abstracts the business process that build upon the services provided in the lower layers. Process layer is responsible for coordination of services (orchestration). - Access layer abstracts the interaction between the service consumers (access channels such as web pages, RFID, portals, etc.) and the services in the process and service layers.
SOA is a high-level refactoring. It can be viewed as a transformation of the “Accidental” architecture to a “Service-Oriented” architecture where Layering is a key principle to enable SOA in terms of loose coupling, reuse, and composition.
This slide highlighs that the alignment between the IT and business units is a key requirement for SOA to succeed in any organization. SOA is a journey jointly undertaken. SOA is a unified goal to achieve. However, we need to also bear in mind that there are other factors that make SOA much more than just this alignment between the units. We need to add the 4Ps of SOA to this conceptual model to make SOA a reality. 1. People – SOA is a mind set that people have to align with to work together towards a common goal. SOA promises to reduce/eliminate traditional barriers between different units in an organizaiton by bringing all of them together to create a unified SOA vision and execution. 2. Process – Mature processes need to be put in place to enable, build, implement SOA. SOA Governance is a huge opportunity and requirement to make SOA succeed. 3. Practice – this is the best practices for implementing SOA. Sun has great leadership in this area with deep architectural expertise and thought leadership in the industry. 4. Platform – this is what we at Sun have built and are confident of providing the best SOA platform out there in the industry today. We will talk about the Sun SOA platform later in this preso.
Business Perspective Separation of Business Services from Processes Increases visibility into business operations Increases flexibility with business process management Closer IT alignment with Business Application Perspective Services can be independently designed, constructed, deployed, maintained, and managed Services enable a loosely coupled architecture Services reuse lowers development risks and reduce development cycles Composite Applications consume existing services and expose new services Information Perspective Simplifies Enterprise Information Strategy by exposing common message data dictionary Services encapsulate and facilitate hiding the complexity of underlying data model promoting usability and reusability Results in lower maintenance cost and decreased cost with shared data services and elimination of redundant data Technology Perspective Provides architectural foundation for consistent, secure, published and contractual infrastructure Enables wrap and reuse of existing systems Allows combining the functionality of multiple systems and provide additional functionality in lower risk, cost effective fashion Leads to better IT execution and alignment with constantly changing business needs
At sun, we have traditionally been very pragmatic about SOA from the start. We do not push products. We focus on the customer's business problem and provide guidance based on the needs. We adopt an incremental and iterative approach during the whole lifecycle of the projects. The focus in our platform is Interoperability and we have been working with Microsoft at all levels to make sure that Java and .NET platforms interoperate. We are completely standards based, yet at the same time do not prematurely adopt a specification. Our platform (as shown later) will be simple to understand because we focus on key SOA design centers of service composition, service control, service delivery and composite application platform. Our platform is comprehensive and yet you can adopt and implement pragmatically.
This is a common mis-conception that SOA = Web Services. SOA is about Architecture. SOA describes an Architectural style where as Web Services represent one important implementation strategy of this Architectural style. The confusion arises because contemporary SOA implementations are heavily leveraging Web Services technology and standards. As show in the SOA and Standards slide, you will see how different WS-* standards and specifications are being used to fulfill different SOA needs in the architecture.
Section <ul><ul><li>Introduction to SOA </li></ul></ul>
Hype or Reality? So What? SOA!? Reuse Encapsulate The New EDI? Remember CORBA? Web Services Aligned Cross-Platform Vendor Neutral Multi-Vendor Register & Discover Described Standards Flexible IT XML Wrap & Reuse Composability Legacy Layering Agile Stateless Loosely Coupled Messaging Integration QoS Federation Transformation On Demand Autonomous Interoperable Extensible Location Transparency
SOA Buzz (the obligatory analyst quotes) <ul><li>SOA is a catalyst for business transformation enabling your business to thrive on change. . . . SOA is a technology-based embodiment of your business (Forrester Research) </li></ul><ul><li>IT must change its primary operating mode from delivering applications to a mode of delivering strategic business flexibility . . . (Forrester Research) </li></ul><ul><li>By 2006, more than 75% of midsize and large enterprises will have deployed SOA-enabled development tools and middleware (Gartner) </li></ul><ul><li>By 2006, more than 60% of enterprises will consider SOA a guiding principle in designing their new mission-critical business applications and business processes. (Gartner) </li></ul><ul><li>By 2007, focus will shift from basic infrastructure to business frameworks via Web services-based, Service-Oriented Architectures. (Meta Group) </li></ul><ul><li>By 2008, SOA will be a prevailing software engineering practice , ending the 40-year domination of monolithic software architecture (Gartner) </li></ul>
What is SOA? (the obligatory definition slide) <ul><li>SOA is an architectural style that emphasizes loosely coupled , coarse-grained , shareable , secure, network based services to enable business flexibility in an interoperable technology agnostic manner. </li></ul><ul><li>SOA is a business & technical strategy to expose business functionality & data within and between enterprises </li></ul><ul><li>SOA is a design paradigm for the creation of applications via the orchestration of stateless services that interact through a variety of standards based interfaces </li></ul><ul><li>SOA is an integrated software infrastructure and design approach based on best practices </li></ul>
Accidental Architecture? Silo Oriented Architecture <ul><li>Rigid </li></ul><ul><li>Complex </li></ul><ul><li>Expensive </li></ul><ul><li>Slow to Market </li></ul><ul><li>Monolithic </li></ul><ul><li>Hard to Integrate </li></ul>Mature information systems grow old dis gracefully as successive waves of hacking result in accidental architectures which resist the reflection of on-going business process change.
Promise of SOA <ul><li>Interoperability </li></ul><ul><li>Federation </li></ul><ul><li>Dynamic Discovery </li></ul><ul><li>Loose Coupling </li></ul><ul><li>Reuse and Composition </li></ul><ul><li>Evolution, not Revolution </li></ul><ul><li>Wrap and Reuse; Not Rip and Replace </li></ul><ul><li>Standards based approach </li></ul><ul><li>Alignment of Business and Technology </li></ul>
Benefits of SOA <ul><li>Flexible IT </li></ul><ul><ul><li>Faster to Market </li></ul></ul><ul><ul><li>Changeable Business Processes </li></ul></ul><ul><ul><ul><li>Meet current/future market conditions </li></ul></ul></ul><ul><li>Simplified Business Integration </li></ul><ul><ul><li>Seamless integration with customers and partners </li></ul></ul><ul><li>Visible Business Process </li></ul><ul><ul><li>Mutable, Extensible, Reusable </li></ul></ul><ul><ul><li>IT Governance and Compliance </li></ul></ul><ul><li>Align IT and Business Units </li></ul>
Sun's Pragmatic SOA Approach <ul><li>Iterative, Incremental adoption and build out </li></ul><ul><li>Interoperable </li></ul><ul><li>Integrated and Integratable </li></ul><ul><li>Simple to understand; Sophisticated to fulfill real-world needs </li></ul><ul><li>Comprehensive Design; Pragmatic Implementation </li></ul><ul><li>Standards-based </li></ul>