Your SlideShare is downloading. ×
Why a Service-Oriented Architecture?
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Saving this for later?

Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime - even offline.

Text the download link to your phone

Standard text messaging rates apply

Why a Service-Oriented Architecture?

297
views

Published on


0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
297
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
9
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Why a Service-Oriented Architecture? Jason Bloomberg Senior Analyst ZapThink, LLC Copyright © 2004, ZapThink, LLC
  • 2. Agenda • What are the problems that SOAs solve? • Why haven’t these problems been solved before? • Just what is SOA, and how is it related to Web Services? • What steps should you take to implement an SOA? • What are the key requirements for SOA? • How might SOA transform your organization? Copyright © 2004, ZapThink, LLC
  • 3. Business Constant: Change Changing Marketplace Customer Competition Demands Mergers & CHANGE Optimizing Acquisitions Processes Business Partners New Technologies A Business is Never STATIC Copyright © 2004, ZapThink, LLC
  • 4. IT: Fulfilling Business Requirements Business Requirements IT Capabilities • Service Customers • Implement CRM Systems • Manage Operations • Implement ERP Systems • Increase Worker Productivity • Manage desktop environments • Communicate with market • Manage server environments • Ensure reliable and secure • Manage email systems and web operations sites • Develop new products and • Manage network and storage services operations • Respond to new business • Develop applications drivers Copyright © 2004, ZapThink, LLC
  • 5. However, it rarely works that way… • Requirements change Business Requirements • Interpretations often inaccurate or limited ? Inter preta IT ti o n • Lengthy development cycles impervious to change • Implementations “cast in t en concrete” Fi na p m lI lo ve le m pl de yc em ng c en Lo Result: IT that places ta t io n limitations on Business Copyright © 2004, ZapThink, LLC
  • 6. The Integration “Rat’s Nest” Client 1 FBT PAY G NTS TRDS Customs NTS A/c Data……. Penalty RBA Def RRE IPS Refunds Integrated A/C 1 Excise Payments CCD Compliance Staff CR ECI ADD AWA ELS Staff Business Phone DDDR TASS PKI CDCC CWMS GCI Bus. Intel IVR WOC Ref material BOA Staff Remote TAX Client BANK Staff AGENTS Call Centers BEP Copyright © 2004, ZapThink, LLC
  • 7. Integration Approaches of Yesterday • Custom Integration: Coding to Interfaces – APIs: COM, Java, COBOL, Assembly? – Distributed Computing?: DCOM, CORBA – Screen-Scraping and Emulation (3270 and HTML) – Message-Queues • EAI and B2Bi Middleware – Automating interface-level integration – Bus or hub-and-spoke architecture Fundamentally brittle approaches to integration Copyright © 2004, ZapThink, LLC
  • 8. What is a Service-Oriented Architecture? • Access software via Services that are easy to find and connect to • Web Services provide a standard way of building and accessing Services • Users can build applications out of Services Copyright © 2004, ZapThink, LLC
  • 9. Have We Been Here Before? • Service-Oriented Architectures have been around a while • CORBA (Common Object Request Broker Architecture) and DCOM (Microsoft Distributed Component Object two familiar examples Model) • What’s new this time? Copyright © 2004, ZapThink, LLC
  • 10. The Difference is Web Services • Standards-based interfaces to software Service Registry functionality UDDI Find Publish WSDL SOAP Bind Service Consumer Service Producer Copyright © 2004, ZapThink, LLC
  • 11. Web Services are the Trees…. Service Orientation is the Forest Copyright © 2004, ZapThink, LLC
  • 12. The Next Big Thing? Programmin Business Approach Timeframe g Model Motivations Mainframe timesharing Procedural 1960s –1980s (COBOL) Automated business Database (SQL) and fat Computing power on Client/server 1980s-1990s client the desktop (PowerBuilder, Visual Basic) Object- n-Tier/Web 1990s-2000s oriented (Java, Internet/eBusiness COM) Service- Service orientation 2000s oriented Business agility (SOAP, WSDL, UDDI) Copyright © 2004, ZapThink, LLC
  • 13. The SOA Implementation Roadmap Just-In-Time Integration Service-Oriented Service-Oriented Process Enterprise Business-Oriented Services Enterprise SOA Buildout Implement the SOA Pilots SOA Metamodel Dynamic Service Discovery Manage Services Mission-Critical Web Services Secure Service Interfaces “Grass Roots” Web Services Implementations Wrap Legacy Systems in Services Interfaces Heterogeneous Systems with Proprietary Interfaces Copyright © 2004, ZapThink, LLC
  • 14. Getting Started: Web Services & Legacy • What is “legacy”? – Host-based systems… – SCM, CRM, and other business apps… – Anything that’s in use… • Legacy systems enable a significant amount of mission- critical functionality • Rip-and-Replace vs. Maintain-and-Extend The first step to extending functionality: abstracting the implementation – aka “Service Wrappers” Copyright © 2004, ZapThink, LLC J
  • 15. Requirements for SOA SOAs abstract the software functionality that business processes compose and orchestrate Service-Oriented Service-Oriented Architecture Process SOM enables loose SOAs abstract the coupling and coarse SOM enables and manages adaptation layer with a granularity business Services and the logical Service network processes that link them Service-Oriented Service-Oriented Integration Management SOM enforces the Quality of Service of SOI Web Services Security & Identity Management Essential prerequisite for SOAs Copyright © 2004, ZapThink, LLC
  • 16. Requirement #1: Security Traditional Distributed Service-oriented Computing computing Network (Packet) Level Application Level TCP/IP packet XML-based inspection Content aware Perimeter-based Application control Closed Systems Open Systems Proprietary, closed APIs Open, accessible APIs Tight coupling Loose coupling Single administrator Multiple administrators Localized users Distributed users Fragmented Control Managed Security Islands of security Maintained as separate Whole network policies units Tiered administration Copyright © 2004, ZapThink, LLC
  • 17. The Problem of Context Copyright © 2004, ZapThink, LLC
  • 18. Requirement #2: Management • Are your Services up and running? • Are the right consumers accessing the right Services? • How do you keep consumers & producers of Services loosely coupled when Services change? • How do you fix things when something goes wrong? • Are you providing the required quality of Service? Copyright © 2004, ZapThink, LLC
  • 19. Requirement #3: Architecture Business Model Platform Service Model (Use Cases) Dependent Models Logical View Line-of-Business Users Business Process View Views Business Analysts Use-case View Service-Oriented Architects Implementation View Technical Architects & Developers Technology Views Deployment View System Architects & Copyright © 2003 ZapThink LLC System Engineers Copyright © 2004, ZapThink, LLC
  • 20. Requirement #4: Process • Processes that are coarse-grained: composed of Services and exposed as Services • Processes that are loosely coupled: a change to a process flow, activity, subprocess doesn’t effect other processes • Processes that are asynchronous • Processes that are dynamically discoverable SERVICE-ORIENTED PROCESSES ARE PROCESSES THAT CAN RESPOND TO CHANGE Copyright © 2004, ZapThink, LLC
  • 21. Managing SO Processes • Achieving Loose Coupling • Managing Atomic Services – Making sure the activities work! – Processes are Services • Managing End-to-end Processes • Keeping the abstraction in place Copyright © 2004, ZapThink, LLC
  • 22. Business-Oriented Services • Complete the abstraction layer, hiding implementation details from line-of-business • Typically are SO Processes • Location independent • Updated and modified without breaking the loose coupling with consumers Copyright © 2004, ZapThink, LLC
  • 23. The Service-Oriented Enterprise • IT resources are available on demand to businesses as Services • The Service-oriented abstraction layer enables companies to run their operations and conduct business with each other in a dynamic and automated fashion • Business drives IT, and agile IT enables agile businesses Copyright © 2004, ZapThink, LLC
  • 24. ZapThink is an industry analysis firm focused exclusively on XML, Web Services, and Service-Oriented Architectures. Take Credit for attending this presentation! • Go to www.zapthink.com/credit and enter the code SOACORD. Thank You! • Download a digital copy of the presentation • Sign up for our ZapFlash newsletter • Get a ZapCredit good toward free research and ZapGear! Jason Bloomberg jbloomberg@zapthink.com Copyright © 2004, ZapThink, LLC