From Components To Services
- 1. From Components to Services –An observation on paying back Technical Debt Presented by Jamie Phillipshttp://devblog.petrellyn.com
- 2. Who is Jamie PhillipsSenior Software Engineer with over 12 years experience in the Telecomm, eCommerce, Finance and Healthcare industries.Professional experience based on the .NET framework (versions 1.0 – 4.0)Passionate about engineering and design principles.Natural ability to adapt to change has lead to becoming a practicing SCRUM Master and evangelist.
- 3. A phrase coined by Ward Cunningham to describe the effect of choosing a design that has high returns in the short term but increases complexity and maintainability in the long term.Debt can be classified as:Unintentional – typically where poor code has been written through ignorance or lack of experience; could be addressed with peer code reviews, etc.Intentional – where design decisions are made for short-term benefit because of release dates (“we’ll sort it out in the next release”) – this is harder to resolve and often requires re-design / re-factoring.What is Technical Debt?
- 4. The fundamental basis of Software Architecture is the reduction of complexity through abstraction and separation of concerns.Good use of Design Patterns and a clear Roadmap lead to good Architecture.Good Software Architecture is essential to the success of a Software company.Poor Software Architecture is the Achilles Heel and can be the catalyst for declining sales of a software product.Thoughts on Software Architecture
- 5. Does not mean “dumbing down”Does mean the division of a large system into smaller, more manageable partsUtilize the simple (and historic) theory of “Divide and Conquer”Once smaller, more manageable parts are defined, system can be overhauled a piece at a time.Reduction of Complexity
- 6. Separation of concerns is achieved by applying fundamental Design Patterns (such as Dependency Injection, MVC, etc).Allows for refactoring and flexibility when changing the design at a latter stage.Facilitates better testing and more robust code.Can become overly complex – needs to be coordinated and thought through.Separation of Concerns
- 7. Roadmaps can encompass Products, Technologies and even Enterprises.Roadmaps help separate business divisions in an enterprise work towards a common goal.Software Architecture is driven by both Technology and Product roadmaps.Technology Roadmaps are the domain of Software Engineering – Product Roadmaps are the domain of Product Marketing / Management.Roadmaps are essential for success.
- 8. With software vendors building on their previous successes/failures:Quite often the foundations are not based on the previously mentioned principles.Products based on out-dated technology and / or design limitations (i.e. not scalable).Tribal knowledge is lost as people move on.Stating the obvious does not always take place – it can be forgotten or overlooked in the mêlée to deliver the next version.So what’s new?
- 9. Start with the exercise of creating the Product and Technology roadmaps.Scrutinize the existing architecture (or lack of) with a view to identifying problem areas.Get buy-in from all involved (Executives to individual contributors); otherwise the effort will be doomed from the beginning.Set expectations early by planning a phased approach – few complex software products can be re-written in a short period of time.It is not too late!
- 10. “A well-placed pebble can change the course of a river.” – unknownUtilize a pilot project as proof of concept.Small dedicated team of domain experienced individuals.Executive sponsor.Minimal impact on main product code line.Provide regular updates, highlighting technologies, patterns used (relate to Roadmaps for validation of work)Once project is complete review the outcomes with a larger audience to familiarize people with the concepts.The pebble
- 11. Services represent capabilities:SOA PrimerWhat is a ServiceI assist the customer in selecting productsFacilitates invoicing the customer for purchases made.SalespersonInvoice ServiceTranslatesI deliver purchased products to customer addressFacilitates organizing inventory according to customer purchases.Delivery DriverInventory Service
- 12. Service Contract is the Interface implemented by the Service Class (Service classes can implement more than one Interface).Operation Contract is one or more methods on the Interface that the Service Class implements.Data Contract is one or more parameter types or return type related to the Operation Contract.SOA PrimerAnatomy of a ServiceIServiceAService AService ACapability XCapability Y
- 13. The Service Inventory represents the sum total of all of the enterprises Services that are available for use.Services are added once they become available.SOA PrimerService InventoryServiceInventory
- 14. Services (from a SOA perspective) bring the following to bear on the Software Architecture:Organizational AgilityImproved InteroperabilityBusiness and Technology AlignmentReduced IT BurdenWhere do Services fit in?
- 15. Refers to the speed and ease which an organization can respond to change.Maintaining an inventory of highly standardized and reusable services facilitate changing requirements.Inventory is built up of standalone services that can be orchestrated in many different topologies for a variety of application uses.Agility comes with maturity and size of inventory – not a one release hit.Organizational Agility
- 16. A variety of Services make up the inventory and is representative of emergent architecture.Organizational Agility (cont)InvoiceTimesheetInventoryServiceInventoryNew services are added as they become available
- 17. Traditional Client-Server applications that are required to work together need periods of integration.Typically, established applications were not designed to interact with each other.Services, by the nature of their design, are implicitly intended to interact with other systems.Services can be “orchestrated” together (from a Service Inventory) to provide the necessary functionality.Improved Interoperability
- 18. Done correctly, Services will force decoupling between various layers of a software system.A system that is too tightly coupled will suffer from (to name a few):High costs for maintenance – any changes that have to be made can be too complicated / too time-consuming.Change is both difficult and painful; refactoring can become so difficult that it may outweigh the effort involved.The more complex the system the harder it is to locate the source of an issue.Improved Interoperability (cont)
- 19. Traditional applications are not always prepared for interoperability - implicit overhead for design and testing.Improved Interoperability (cont)
- 20. Services, by their nature, are prepared for interoperability from the get-go.Services can be orchestrated together to provide specific functionality.Improved Interoperability (cont)ServiceInventoryServiceComposition
- 21. Services can be defined in terms of their business assets as opposed to simple grouping of functional capabilities.Business and Technology AlignmentProcessOrderBusiness ProcessDefinitionInvoiceInventoryBusiness EntityModel
- 22. Enterprises that offer suites of integrated applications; often carry the burden of tight coupling and spaghetti references (built up over time)Reduced IT Burden
- 23. Services are profiled and documented in a Service Inventory that can be used to build functionality for a variety of different applications.The inventory reduces clutter and clearly defines the capabilities.Reduced IT Burden (cont)
- 24. Two client-server applications originally designed for different aspects of the same domain.FaceForward is a client application for the Sales division; uses its own database for storing client information and sales information.DispatchIt is a backend application for the Shipping division; uses its own database for storing shipping information (with some client information)A tale of two productsFictional case study based on actual experiences
- 25. A tale of two productsFictional case study based on actual experiences.In the beginning: Two separate products in their own rightFaceForwardDispatchItUIUIBusiness LogicBusiness LogicData AccessData Access
- 26. A tale of two productsFictional case study based on actual experiences.Then: Products “merged” as an application suite.FaceForwardDispatchItUIUIBusiness LogicBusiness LogicData AccessData AccessTriggers / componentsused toSynchronize commondata
- 27. A tale of two productsFictional case study based on actual experiences.Migration towards Services – identify new common features.FaceForwardDispatchItNew functionalitytakes advantage of the new architecture.UIUIBusiness LogicBusiness LogicData AccessData AccessServices
- 28. A tale of two productsFictional case study based on actual experiences.Services begin to form basis of architecture.FaceForwardDispatchItOver successive releasesmore and more featuresuse the new architecture.UIUIBusiness LogicBusiness LogicData AccessData AccessServices
- 29. A tale of two productsFictional case study based on actual experiences.Services assume bulk of processing for thin clients.FaceForwardDispatchItUIUIServices
- 30. Services provide ideal decoupling because the service consumer only needs to know about:the Service interface (Service Contract).what methods (Operation Contracts) are available.what parameters (Data Contracts) are needed.Typically service calls are done through XML Serialization / De-Serialization, so consumers have no knowledge / dependency on the Services dependencies.Services from a client perspective
- 31. BOnce a component contains a reference, it exposes these references to calling components.Typical Component Dependency TreeApplication A contains implicit references to components D and EACDE
- 32. Due to the nature of the Service Contract the underlying references of a Service are not exposed:Services hide underlying referencesApplication A contains explicit references to the Service Proxy and has no concept of components D and E used by the Service class B.ABDE
- 33. Phase 1 – inject the “call-through” Service between client and components.Migration from Component Architectureto Services ArchitectureServiceBBDEDE
- 34. Phase 2 – replace “call through” Service external references with new internal modules.Migration from Component Architectureto Services ArchitectureServiceServiceBB1DED1E1
- 35. SOA Principles –http://www.soaprinciples.com/SOA Patterns –http://www.soapatterns.org/What is SOA –http://www.whatissoa.com/Reference material