Why SOA? Simplifying Processes Interoperability with a Service Oriented Architecture Zak Merzouki, Software Architecture and Technology Director BDPA 11/20/2008
Perspective "Things should be made as simple as possible, but no simpler. "Artificial dependencies should be reduced to the minimum but real dependencies should not be altered. Albert Einstein 2007 Camstar Systems. All rights reserved. 2
Agenda Background Why SOA? Applicability Case Study Conclusion 2007 Camstar Systems. All rights reserved. 3
Core Drivers Influencing The Camstar Architecture New Functional Capabilities Closed-Loop Processes between Manufacturing, Quality and Intelligence Role-based collaboration Richer Industry-Level Specializations Life Sciences, Semiconductors, High-Tech and Solar Better Interoperability Cross-platform communication Emphasis on innovation driven by key success factors Rapid Deployment Enterprise Class Solution 2007 Camstar Systems. All rights reserved. 4
Key Challenges Implement Manufacturing and Quality requirements in a closed-loop Seamless transitions between Manufacturing and Quality Eliminate Interoperability limitations Compliance to established standards Rapid Deployment means Flexibility, Adaptability and Efficiency Needs to be addressed at the Architectural level 2007 Camstar Systems. All rights reserved. 5
Camstar Approach Complement our Solution Portfolio set by enabling a Services Driven Manufacturing & Quality Architecture Based on SOA (Services Oriented Architecture) principles, the architecture allows us to meet our requirements for: Interoperability Flexibility Adaptability Efficiency 2007 Camstar Systems. All rights reserved. 6
Why SOA? Attempts to improve Agility and Efficiency by homogenizing systems through the introduction of Enterprise Wide IT standards Structural Approach Componentized Approach Enterprise Data Model Enterprise Service Bus Service Oriented Architecture 1980s 1990s 2000s New Gen 2007 Camstar Systems. All rights reserved. 7
Lessons Learned For the last two decades, standardization efforts in IT have generally failed to deliver easy integration Structural level focus Common Enterprise Data Model (EDM) As many different database schemas out there as there are DBMS in a company Middleware Technology Standards (ESB) meant to be ubiquitous and technology-independent In addition to application heterogeneity we are also facing the problem of middleware heterogeneity (CORBA, DCOM, SOAP, etc) 2007 Camstar Systems. All rights reserved. 8
What s the difference this time? Isn t SOA yet another enterprise wide standardization effort this time under the label of the Enterprise Service Bus? SOA is neither a Technology nor a Technology Standard, but instead represents a Technology-independent set of principles which provide Architectural Blueprints 2007 Camstar Systems. All rights reserved. 9
SOA In A Nutshell SOA means accepting the heterogeneity of platforms, as well as the fact that things change constantly SOA is about a fundamental transformation of the systems landscape into loosely coupled building blocks (or Services) SOA means focusing on the external structure of these Services The Services have a clearly articulated value to the business Interface standardization in an SOA is important but secondary, because adding interfaces (new functionality or additional access protocols) to a well designed SOA building block is affordable 2007 Camstar Systems. All rights reserved. 10
Services vs. Web Services Services and Web Services are related but not identical Services and Web Services use SOAP, XML, XSD, WSDL and other standard protocols Web Services are limited to HTTP request/reply type of communication Services are free to use other transports (i.e. TCP, MQ, etc) and other message exchange patterns 2007 Camstar Systems. All rights reserved. 11
SOA in Manufacturing & Quality Manufacturing & Quality requirements could be seen as a Specialized Instance of an SOA Designed to support a broad array of Practices Requirements may vary but many Generic Services are common Generic services could be used and/or reused by different lines of business Usage could be constrained by a set of regulatory requirements 2007 Camstar Systems. All rights reserved. 12
Case Study: Applying SOA Principles To Camstar Architecture Zak Merzouki, Technology Director
Current SOA Infrastructure Camstar has been applying SOA patterns for years The MES Application (InSite) is exposed, unchanged, as a Web Services interface (based on ASP.NET Web Services) Camstar provides four Web Services interfaces to the InSite Application This pattern provides Access, and a measure of Reuse and Flexibility Other interfaces to external clients XML APIs (.NET and Java) XML Connect Camstar Open Adaptor 2007 Camstar Systems. All rights reserved. 14
Challenges Complexity and heaviness of underlying data model partially abstracted away by the Web Services No compliance to interoperability standards (WS-I, WS-*) Security is handled directly by the Application Server vs. the Service All Web Services need to be re-generated with every Business Logic and Schema update Web Services are compiled at first run 2007 Camstar Systems. All rights reserved. 15
Camstar Directions New Application Services Architecture follows core SOA principles as they relate to Loose coupling, Autonomy and Reusability Specialized instance of Manufacturing, Quality and Intelligence Services High level of granularity Complexity of underlying data model is abstracted away New Services for handling Security Authentication and Role-based Access Control External Notification To mail server 2007 Camstar Systems. All rights reserved. 16
Three Axis 1. Market Requirements Market Problems & Specialized Use Scenarios based on Real-Life examples 2. Enterprise Class Standardized Interoperability Emphasis on Scalability, Performance, Security, Deployability and Maintainability 3. Best Practices Design and Development Patterns & Practices 2007 Camstar Systems. All rights reserved. 17
Architectural Principles Architecture follows Services Orientation principles: Implementation neutral Autonomous Share Schemas and Behaviors only Application Services are free to use any Transports (HTTP, TCP, etc) and Message Exchange patterns (Simplex, Duplex, etc) Services can be accessed through a User Interface, System Interface and/or Equipment Interface 2007 Camstar Systems. All rights reserved. 18
Advantages Performance Shows response time gain over current implementation Deploying new services as granular set of assemblies significantly reduces in-process memory load at first run Scalability Server throughput improvement by 25-50% Configurable transport bindings (i.e. Basic HTTP, WS-HTTP, TCP, etc) Selective way for generating granular services Supports Sync and Asynchronous communications (i.e. AJAX-Style) 2007 Camstar Systems. All rights reserved. 19
Application Services Compliance Application Interoperability compliant to WS-Interoperability (WS-I) Formal Market Requirement Basic Profile 1.1 Infrastructure Interoperability compliant to WS-* Specified by OASIS WS-I Compliance Test & Verification done by QA 2007 Camstar Systems. All rights reserved. 20
Conceptual Representation 2007 Camstar Systems. All rights reserved. 21
New SOA Infrastructure Services Componentization Application is deconstructed into highly granular services components (WCF) This pattern provides the maximum value of Access, Reuse and Flexibility Compliance to established standards Leveraged for internal and external integration 2007 Camstar Systems. All rights reserved. 22
Conclusion Camstar relies on Application Services available to external clients to facilitate Manufacturing and Quality Processes Implementation Based on Loosely Coupled collaboration between Services Integrating to Camstar Applications means: Communicating through WS-I compliant Application Services Platform Independence (i.e..net, J2EE, etc) 23 2007 Camstar Systems. All rights reserved. 23
Q&A 2007 Camstar Systems. All rights reserved. 24
Thank You 2007 Camstar Systems. All rights reserved. 25