SOA vs Past Architecture

SOA vs Client Server

• Mainframes provided the first “client-server” computing with synchronous and asynchronous communication

• CICS – conversational and non-conversational 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 runs 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

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

• 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

• 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

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

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

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

• 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

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.

• 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

• 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

• 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

• 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

• 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

• Messages are structured to be self-sufficient

• 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, de-serialization of SOAP messages containing XML payloads

• RPC communication is faster than SOAP and SOAP processing overhead is a significant design issue

• Messaging framework supports a wide range message exchange patterns

• Asynchronous patterns encouraged

• Support for stateless services is supported by context management options (WS-Coordination, 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

• SOA requires additional runtime administration:

– Problems with messaging frameworks

– Additional administration of a private or public registry of services