Why SOA? Why SOA? Simplifying Processes Interoperability with ...

Why SOA? 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

©2007 Camstar Systems. All rights reserved. 2

"Artificial dependencies should be reduced to the minimum

but real dependencies should not be altered.“

Albert Einstein

Agenda

• Background

• Why SOA?

• Applicability

• Case Study

• Conclusion


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


• Better Interoperability

• Cross-platform communication

• Emphasis on innovation driven by key success factors

• Rapid Deployment

• Enterprise Class Solution

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

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


• Interoperability

• Flexibility

• Adaptability

• Efficiency

Componentized ApproachStructural Approach

Why SOA?

• Attempts to improve Agility and Efficiency by homogenizing

systems through the introduction of Enterprise Wide IT

standards


Enterprise

Data Model

Enterprise

Service Bus

1980s 1990s 2000s New Gen

Service Oriented Architecture

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


� 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)

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


which provide Architectural Blueprints

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

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


• Services are free to use other transports (i.e. TCP, MQ, etc) and other

message exchange patterns

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


common

• Generic services could be used and/or reused by different

lines of business

• Usage could be constrained by a set of regulatory requirements

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

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

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

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

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

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%


• 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)

Application Services Compliance

• Application Interoperability compliant to WS-Interoperability

(WS-I)

• Formal Market Requirement

• Basic Profile 1.1

• Infrastructure Interoperability compliant to WS-*


• Infrastructure Interoperability compliant to WS-*

• Specified by OASIS

• WS-I Compliance Test & Verification done by QA

Conceptual Representation


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


• Compliance to established

standards

• Leveraged for internal and external

integration

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:


• Integrating to Camstar Applications means:

• Communicating through WS-I compliant Application

Services

• Platform Independence (i.e. .NET, J2EE, etc)

23

Q&A


Q&A

Thank You


Thank You

Why SOA? Why SOA? Simplifying Processes Interoperability with ...

Documents