AMP/ADTECH SOA Workshop. August 2017

Transcription

1 AMP/ADTECH SOA Workshop August 2017

2 Software Developer Generations (1) Four Generations of Software Developers 1 st Generation 1950s through the 1960s 2 nd Generation 1970s through the 1980s 3 rd Generation 1990s through the 2000s 4 th Generation 2010s to now 1 st Generation Developed Operating Systems Developed Compilers Developed data access & Hierarchical databases (e.g. VSAM & IMS) Discovered and codified software design principals 2 nd Generation Developed Distributed Transactional Processing (e.g. CICS) Developed Relational DataBases (e.g. DB2) Custom single tier software applications (accounting, banking, etc.)

3 Software Developer Generations (2) 3 rd Generation Developed Commercial-Off-the-Shelf (COTS) Applications SAP, PeopleSoft, etc. Accounting, Banking, ERP, etc. Migration to distributed systems Client-Server architecture (Two tier) N Tier architecture Exploitation of the Internet & Open Standards 4 th Generation Mobile devices becoming a primary platform Software as a product (e.g. embedded APIs)

4 Development Challenges over Time 1 st Generation Development of basic Engineering Practices Development of standard I/O mechanisms 2 nd Generation Data Integrity / Transactions Distributed Data Processing engines and XA implementation Avoiding the brittleness of software based around data SQL & Relational DataBases 3 rd Generation Inter-platform connectivity HTTP & the loss of transactionality Managing application complexity in a multi-platform environments More moving parts More technologies & standards

5 Constant Development Challenges Skill Sets Corporate investment in skill pools Overlapping capabilities Use the tool you know Software Costs Time to Market Cost to Build Cost to Maintain Software Complexity More complicated = More expensive KISS is not easy

6 Development Challenges driving SOA Time to Market too long Large complicated systems Tightly coupled software complicated local changes Use the tool you know Software Costs too high Root Cause of Issues Increasing software functional complexity Systems continually expanding and enriching functionality Increasing software system complexity More computing platforms, languages, standards, etc. Tight coupling of software components Use of the tool you know approach If you re a hammer, all problems look like nails

7 Software always starts simply

8 The Laws of Entropy always intrude

9 The SOA Solution Back to Basics Design for loosely coupled components Design for highly cohesive components Apply the principles of Structured Design to systems KISS Design software in the same manner as hardware Structured sequences of single-purpose components Component interconnectivity via a standardized bus The software analog of a hardware component is a Service Service Oriented Architecture Component based Bus based Defined & standardized component interfaces

10 The SOA Operational Systems (1)

11 The SOA Operational Systems (2) Interaction Service User or Software Interface Layer A true layer! WebSphere Portal Server Partner Service A second User or Software Interface Layer A marketing layer! WebSphere Commerce Server Process Service Process Layer A true layer! Process logic extracted from business logic. Process modeling enabled as an abstraction (BPEL). WebSphere Process Server / Business Process Manager. Information Service (IaaS) Abstracting information storage/retrieval A true layer. Abstracting SQL, etc. InfoSphere Information Server.

12 The SOA Operational Systems (3) Enterprise Service Bus Communication, Routing. Transformation - A true layer! Connections, Asynchronous Messaging, Routing, Transformation WebSphere MQ WebSphere Message Broker / IBM Integration Bus Access Services A second piece of the ESB A marketing layer! WBIA, Crossworlds Business Application Services Application Hosting Environments A true layer! CICS, WebSphere Application Server

13 Application Structure - 1

14 Application Structure - 2

15 Application Structure - 3

16 Application Structure - 4

17 Application Structure - 5

18 Application Structure - 6

19 An Application in SOA - 1

20 An Application in SOA - 2

21 An Application in SOA - 3

22 An Application in SOA 4

23 An Application in SOA - 5

24 SOA using Spaghetti

25 The SOA Environment

26 SOA Objectives - Recap Goal #1 - Agility Deploy software to market more quickly Reuse infrastructure patterns Minimize impact upon existing applications Modest reuse of new/existing business software Concept is to assemble business solutions from available services Easy access to existing business logic Rapid development of new business logic Goal #2 - Cost Reduction Minimize new solution impacts upon existing systems Achieved through loose coupling Achieved through high cohesion (reduces/isolates new development) Faster time to market

27 ESB Quality of Service Different ESB implementations have different qualities of service WMQ/WMB, WESB, Web Services, ETL The implementation chosen should be based on the quality of service required Connectivity Network connectivity Operating System / Runtime environment support Programming language support / Ease of use Integrity Data Integrity / Transactional support Reliability Availability (Uptime) Monitoring (Proactive Management) Agility Decoupling of endpoints Ease of modification / insertion of new function / transparency to end-points Routing and transformation Security

28 ESB Implementations Enterprise Service Bus Web Services Messaging Extract, Transform, Load (ETL) Web Services Fundamentally a Remote Procedure Call Tightly coupled point-to-point solution Lowest quality of service Maximum connectivity Messaging ETL Loosely or tightly coupled solution Highest quality of service: Routing, Transformation, Value-Add processing enabled Transactional, requires messaging engine and broker Alternative to messaging Optimized for batch, requires ETL engine

29 Services Every program ever written has an interface. Data is passed by content or by reference. Interface may be called a Service. Interface may be called an API. Not every program written will be a Service with a wide potential. Most programs/services are local/tactical rather than strategic/enterprise. These programs/services will still be executed in SOA middleware. These programs/services will require minimal management. Some programs/services will be Enterprise in nature/potential. These programs/services must be managed and controlled. In most shops, this is a handful of Services. Service Invocation Invocation should not be limited by channel (e.g. Web Service vs messaging). Invocation should not be limited by runtime environment. Invocation should be seen as a front-end channel to a service. Service Versioning

30 Application Programming Interfaces (APIs) SOA vis a vis API SOA Services and API interfaces are identical in function: Allow software to intercommunicate with other known interfaces. Increase capability and speed deployment through component assembly rather than build from scratch. SOA Services and API approaches are complementary rather than competitive Everything we have been through with SOA is being rediscovered / reinvented in APIs SOA Generally internal to corporations Primarily, but not exclusively, Intranet based Generally services are proprietary to corporation APIs Akin to Open Source Primarily Internet based & heavily Web Service oriented

31 Side Effects of Services Ownership If software is shared, who owns it? Management If software is shared, who performs change control? Notification? Testing? Performance? Tools Monitoring How do you predict the shared load on software? When will it break?

32 The SOA Lifecycle Discover Construct & Test Compose Integrate people Integrate processes Manage and integrate information Gather requirements Model & Simulate Design Financial transparency Business/IT alignment Process control Manage applications & services Manage identity & compliance Monitor business metrics

33 2351 N. Forest Rd. Suite #120 Getzville, NY (716) Thank You!!