SOA

Chapter 4 The Evolution of SOA

An SOA Timeline XML to Web Services to SOA

XML was a creation of W3C Derived from SGML Designed to expose the structure of a document for processing Adds intelligence to ordinary documents XML gained in popularity in the eBusiness movement of the 90s Server side scripting made conducting business via the internet possible

SOA Timeline
XML allowed developers to attach meaning and context to a document that was transmitted across internet protocols XML was used as the basis for additional standards including XSD (schema definition) and XSLT (transformation language)

XML
XML data representation is the foundation layer of SOA XML establishes the structure of messages traveling between services XSD schemas preserve the integrity and validity of message data XSLT is used to enable communication between disparate data representations by schema mapping

Web Services
W3C recieves Simple Object Access Protocol (SOAP) in 2003 SOAP messages now represent the communications layer for SOA This provided a proprietary-free Internet communications layer This led to the idea of creating a pure, Webbased, distributed technology Web services This helped bridge the enormous disparity between and within organizations

Web Services
The most important part of a Web service is its public interface This is the central piece of information that assigns a service an identity and enables its invocation WSDL (Web Services Description Language) was one of the first initiatives in support of Web services WSDL was submitted to W3C in 2001

Web Services
Web services required an Internet-friendly and XML-compliant communications format Other alternatives were considered (XML-RPC), but SOAP was the winning technology W3C responded by releasing newer versions of SOAP that allow RPC-style and document-style messages SOAP became a standalone term as the acronym no longer matched the purpose

UDDI
Universal Description, Discovery and Integration Submitted to OASIS Allows for the creation of standardized service description registries Services can be registered in a central location and discovered by service requestors Unlike WSDL and SOAP, UDDI hasnt yet attained industry-wide acceptance Remains an optional extension to SOA

Custom Web Services

Custom services were developed to accommodate specialized business requirements Existing messaging platforms (Message Oriented MiddleWare MOM) incorporated services to support SOAP Some organizations incorporated Web services for B2B data exchange replacing EDI (Electronic Data Interchange)

Brief History of SOA

It became clear that Web services could be the basis for a separate architectural platform Early SOA is modeled around three basic components:
Service Discover and Retrieve WSDL Registry Publish WSDL

Service Service Service Provider Provider Requestor Exchange Soap Messages

SOA Extensions
This early model has been extended by WS-* specifications The goal was to elevate Web services technology to an enterprise level There was also an interest in applying serviceoriented concepts to business analysis This vision was supported by the rise of business process definition languages WSBPEL

SOA History
Business Process Management models (BPM) can now be expressed in a concrete executable format SOA is still evolving New standards are still be developed and adopted

SOA Affects XML and Web Services

XML and Web services platforms have had to change in order to adapt to SOA architectures Older distributed applications using XML and Web services have to be modified

Retrofitting Issues
Data Representation and Service Modeling standards must be aligned SOAP is used for all inter-service communication. XML documents and XSD schemas are modeled with SOAP in mind Document-style messaging is standard. Changing from RPC-style imposes changing on services

Retrofitting Issues
SOAP promotes a content and intelligence-heavy message model. This supports statelessness, autonomy and minimizes message sending RPC-style messaging supported granular XML documents with targeted data Transition models for applications may be needed until advance messaging with WS* is available

Continuing SOA Evolution

The evolution of WS-* standards will affect any SOA solution you build Standard an excepted industry technology. All first generation Web services, XML and its related standards Specification A proposed or accepted standard, described within a specification. XML, Web services and all WS-* extensions exist within specifications Extension a WS-* specification or feature

Standard Organizations
Internet standards organizations have agendas that overlap and are not always distinct The primary contributors to vendor-neutral standards are the vendors themselves

Standard Organizations
The World Wide Web Consortium (W3C)
Founded by Tm Berners-Lee in 1994 Began with HTML XML, XML Schema, XSLT, SOAP, WSDL, and Web Services Formal and rigorous with many public reviews Two to three years for standards to be adopted

Standard Organizations
Organization for the Advancement of Structured Information Standards (OASIS)
Created in 1993 as SGML Open Renamed when their scope changed from SGML to XML standards Over 600 organizations WS-BPEL, ebXML, contributions to UDDI, SAML (security), XACML Focuses on core, industry-agonostic standards, leveraging standards to support vertical industries Shorter development times than W3C

Standard Organizations
The Web Services Interoperability Organization (WS-I)
Does not create new standards but ensures the goal of open interoperability 200 organizations, all major SOA vendors Basic Profile a recommendation-based document that establishes which available standards form the most desirable interoperability architecture Positions specific versions of WSDL, SOAP, UDDI, XML, XML Schema Basic Security Profile

Some Major Vendors

Microsoft, IBM, BEA Systems, Sun Microsystems, Oracle, Tibco, HewlettPackard, Canon, Commerce One, Fujitsu, Software AG, Nortel, Verisign, WebMethods

Vendor Influence
Each vendor has its own vision for SOA IBM uses WebSphere Microsoft supports .NET and its operating system Vendors try to influence decisions using proprietary designs

Vendor Alliances
Vendors form loose alliances for common goals IBM, Microsoft and BEA have collaborated on several WS-* extentions OASIS supported WS-ReliableMessaging. Microsoft and IBM announced their own specification WS-Reliability, which has become the contender

Why You Should Care

When migrating to SOA, the maturation process of the standards must be considered Watching standards allows you to gage which ones will succeed Watching standards clues you into trends Maintaining a vendor-neutral perspective is wise

Roots of SOA
With the rise of multi-tier applications, the variations with which applications could be delivered began to increase A definition of a baseline definition application becomes important The definition is abstract but describes the technology, boundaries, rules, limitations and design characteristics that apply to all solutions an application architecture

Application Architecture
An application architecture is a blueprint Different levels can be specified, depending on the organization Might include physical and logical representations, data models, communication flow diagrams, security requirements Several application architectures may exist in an enterprise and kept in alignment by an enterprise architecture

Enterprise Architecture
Enterprise architectures provide high-level views of all forms of heterogenity Urban plan for a city Contain a long-term vision of how an organization will evolve its technologies

Service Oriented Architecture

Spans both enterprise and application architecture domains Benefits of SOA are realized when applied across multiple solution environements Because SOA is a composable architecture, a company may have multiple SOAs

SOA vs Client Server

Mainframes provided the first clientserver computing with synchronous and asynchronous communication CICS conversational and nonconversational mode 1980s two-tier client server with fat clients, GUI, database. Dominated the 90s

Client Server Characteristics

Bulk of the application logic resides with the client Monolithic executable on client Business rules were maintained in stored procedures and triggers on the database This abstracted a set of business logic from the client and simplified data access programming Overall, the client ran the show

SOA Characteristics
Presentation layer can be any software capable of exchanging SOAP messages SOA principles dictate partitioning logic into autonomous units SOA units of logic are solution agnostic

Client-Server Application Processing

80% - workstation, 20% server Even so, the database is often the bottleneck Two-tier solutions usually mean each client has a database connection Connections are often synchronous and persistent 80% processing on client may mean client programs run exclusively

SOA Characteristics
Processing with SOA is highly distributed Each service has explicit functional boundaries and resource requirements SOA allows many options for deploying services Enterprise solutions consist of multiple servers with sets of Web services and supporting middleware With SOA there is no fixed processing ratio

SOA Characteristics
Supports synchronous and asynchronous communication between service and requestors Messages are loaded with intelligence to support message-level context management Smart messaging promotes stateless and autonomous services

Client-Server Application Technology

The technology set for client-server applications included 4GLs like VB and PowerBuilder, RDBMSs The SOA technology set has expanded to include Web technologies (HTML, CSS, HTTP, etc) SOA requires the use of XML data representation architecture along with a SOAP messaging framework

Client-Server Application Security

Centralized at the Server level Databases manage user accounts and groups Also controlled within the client executable Security for SOA is much more complex Security complexity is directly related to the degree of security measures required Multiple technologies are required, many in WS-Security framework

Client-Server Application Administration

Significant maintenance costs associated with client-server Each client housed application code Each update required redistribution Client stations were subject to environment-specific problems Increased server-side demands on databases

Client-Server Application Administration

SOA solutions are not immune to client-side maintenance challenges Distributed back-end supports scalability, but new admin demands are introduced Management of server resources and service interfaces may require new admin tools and even a private registry Commitment to services and their maintenance may require cultural change in an organization

RailCo Case Study

Accounting system is class two-tier GUI front-end is a single executable, deployed on old Windows workstations Only two or three users at a time Outmoded RDBMS OS upgrades produce erratic behavior on some pages Workstations rarely upgraded and are underpowered New Records management policy requires supplementary forms not supported by system

RailCo Case Study

SOA solutions eliminate dependency on user workstations by delegating all processing to server-side SOA establishes extensible architecture model that allows solutions to be enhanced with minimal impact Services can encapsulate existing legacy logic providing a standardized API for larger integrated solutions

SOA vs Traditional Distributed Internet Architecture

Muliple client-server architectures have appeared Client-server DB connections have been replaced with Remote Procedure Call connections (RPC) using CORBA or DCOM Middleware application servers and transaction monitors require significant attention Multi-tiered client-server environments began incorporating internet technology in 90s.

SOA vs Traditional Distributed Internet Architecture

The browser shifted 100% of application logic to the server Distributed Internet architecture introduced the Web server as a new physical tier HTTP replaced RPC protocols

SOA vs Traditional Distributed Internet Architecture

Distributed Internet application put all the application logic on the server side Even client-side scripts are downloaded from the server Entire solution is centralized Emphasis is on:
How application logic is partitioned Where partitioned units reside How units of logic should interact

SOA vs Traditional Distributed Internet Architecture

Difference lies in the principles used to determine the three primary design considerations Traditional systems create components that reside on one or more application servers Components have varying degrees of functional granularity Components on the same server communicate via proprietary APIs. RPC protocols are used across servers via proxy stubs

SOA vs Traditional Distributed Internet Architecture

Actual references to other physical components can be embedded in programming code (tight coupling) SOAs also rely on components Services encapsulate components Services expose specific sets of functionality Functionality can originate from legacy systems or other sources

SOA vs Traditional Distributed Internet Architecture

Functionality is wrapped in services Functionality is exposed via open, standardized interface, irrespective of technology providing the solution Services exchange information via SOAP messages. SOAP supports RPC-style and document-style messages Most applications rely on document-style

SOA vs Traditional Distributed Internet Architecture

Messages are structured to be selfsufficient Messages contain meta information, processing instructions, policy rules SOA fosters reuse on a deep level by promoting solution-agnostic services

Application Processing
Distributed Internet architecture promotes the use of proprietary communication protocols (DCOM, CORBA) SOA relies on message-based communication Messages use serialization, transmission, deserialization of SOAP messages containing XML payloads RPC communication is faster than SOAP and SOAP processing overhead is a significant design issue

Application Processing
Messaging framework supports a wide range message exchange patterns Asynchronous patterns encouraged Support for stateless services is supported by context management options (WSCoordination, WS-BPEL

Technology
Distributed Internet architecture now includes XML data representation XML and Web services are optional for distributed Internet architecture but not for SOA

Security
When application logic crosses physical boundaries, security becomes more difficult Traditional security architectures incorporate delegation and impersonation as well as encryption SOAs depart from this model by relying heavily on WS-Security to provide security logic on the messaging level SOAP messages carry headers where security logic can be stored

Administration
Maintaining component-base applications involves:
keeping track of individual components tracing local and remote communication problems Monitoring server resource demands Standard database administrative tasks

Distributed Internet Architecture introduces the Web server and its physical environment

Administration
SOA requires additional runtime administration:
Problems with messaging frameworks Additional administration of a private or public registry of services

TLS Case Study

TLS Accounting system is a large, distributed component-based solution Components exist on separate application servers:
Web server hosting server-side scripts that relay HTTP requests to components on application servers and process responses An application server hosting a controller component that generates transaction context and manages specialized components

TLS Case Study

Components exist on separate application servers:
A possible second application server hosting two or more business components that enforce specific business rules. This server may host components that encapsulate data access logic A database server hosting a complete RDBMS

TLS Case Study

Issues with the accounting system:
Many components were customed developed to alter existing functionality. Each redevelopment project is increasingly expensive (lots of testing and redeployment) State management was never standardized. Some components manage state by caching data in memory, others use application server-deployed databases XML was introduced and Permanent state management designs already had a relational storage format (not XML)

TLS Case Study

SOA establishes a loosely coupled relationship between units of processing logic. This allows services to be updated and evolved independently of existing service requestors SOA promotes the standardization of XML throughout solution requirements. Service statelessness is emphasized by deferring state management to the message level

Service Orientation and Object Orientation

SO emphasizes loose coupling between units of processing logic (services) OO supports reusability of loosely coupled programming routines, much of it is based on predefined class dependencies, resulting in tightly bound processing logic (objects) SO encourages coarse-grained interfaces (service descriptions) with information loaded messages OO supports fine-grained interfaces (APIs) so units of communication (RPC or local API calls) can perform various tasks

Service Orientation and Object Orientation

SO expects the scope of a service to vary significantly OO objects tend to be smaller and more specific in scope SO promotes activity-agnostic units of processing logic (services) that are driven into action by intelligent messages OO encourages the binding of processing logic with data into objects

Service Orientation and Object Orientation

SO prefers services be designed to remain as stateless as possible OO promotes binding data and logic into stateful objects SO supports loosely coupled services OO supports composition but also inheritance among classes which leads to tightly coupled class dependencies