SOA Programming Model and Physical Architecture Model

Loutfouz Zaman (Shumon)

Two goals of SOA Programming Model

The model must support the languages which were already employed in the information system (J2EE,.NET,XML,DB2,etc) to preserve existing investments and skills The model must mask the differences between languages and environment (to simplify programming and maximize reuse of SOA apps)

Abstraction of SOA

To meet the goals, a high level abstraction was introduced It allows to assemble components without knowledge of the underlying technologies It allows to customize the components through metadata properties The model still allows you to drill into unique aspects of the underlying components (whenever high level programming fails to provide enough details for certain requirements). Its called Progressive Disclosure

Order-entry example

Implement to the business and to the service design not to the underlying implementation. Program should be about order-entry not about J2EE Stateless SessionBeans. SessionBeans is the appropriate technology to implement order-entry service, but it should our secondary concern from the perspective of SOA application development

Six aspects of application design

user interaction (presentation) logic control or business logic information (data) logic composition logic service interaction the backplane of design and policy metadata from which schema, relationships, data types, and constraints are derived dynamically (the first five aspects rest on this aspect)

Three main concepts

Service components implement services (regardless of whether they are interaction services, process services, business application services, information services, access services or partner services) Data is exchanged between services as Service data Services are invoked over a service bus

Service Components

a technology and language-neutral representation of your services. fundamental building blocks from which SOA applications are assembled. abstract components, representing the service implementation in a common way regardless of the actual underlying implementation technology. represent either basic application services or service compositions logic is encapsulated within a service component (presentation, business or data logic) are hosted in a service container an equally abstract representation of the underlying implementation technology container.

Service Data
a language and technology-independent representation of the data you send between services to operate on. Can be thought of as a document that your services exchange (e.g. document containing a loan application or a purchase order which is sent to credit enquiry or to a billing service)

Service Bus
is meant to be entirely transparent to the programming model, but its presence is important to the model It can be assumed that it exists, and there is no need to go into details about it.

Purpose of roles

the purpose of distinguishing roles is to identify the expectations of responsibility, skills, and tools that are relevant to each of these roles. differentiating roles may or may not require differentiating the individuals who have those roles. it is likely that a single individual may hold multiple roles within the SOA processes It is also likely that a given role may require many individuals to fulfill the role for a large organization.

Roles

Business Analyst - responsible for knowing the business processes in the design and capturing them in a model that can be used by the rest of the development team (Uses modeling tools for that purpose) Participates throughout the development cycle to refine and optimize the business design and establish its key performance indicators Refines the business design or drives changes in its implementation verifies that the IT realization faithfully implements the business design.

Roles(2)

Integration Specialist - responsible for integrating services, and end-users into the business process definition (the service composition components). is also involved in establishing an approach to satisfying the security and QoS requirements of the enterprise (together with Enterprise Architect) Typically uses visual composition tools and service-bus configuration tools to wire abstract service components.

Roles(3)

Software Architect - responsible for translating the business design into a set of software component design specifications for implementing the service definitions and business objects. May design the internal workings and structure of the actual service components. Makes decisions about the appropriateness of legacy function to the design, and determines how to wrapper, extend or re-factor that legacy function (together with Enterprise Developer)

Roles (4)
Application Developer - responsible for implementing the design for service provided by the software architect. Utilizes appropriate language and technology to implement the services following the design given by the software architect

Roles(5)

Enterprise developer - a specialist in legacy application functions, languages and technologies responsible for assisting the software architect to identify potential re-use of legacy application functions Helps the software architect to determine how best to extend or re-factor legacy application functions to enable a better fit with the business design.

Roles(6)
Enterprise Architect oversees and conducts the entire process. Ensures consistency across each roles tasks Tries to balance the creation of implementation artifacts (representing the business design) against the constraints, preferences, and legacy capabilities.

Other roles

Other roles in SOA developing process are more traditional and aren't affected by SOA foundation. Here are some: data architect database administrator deployment administrator support specialist And others

Tasks of SOA modeling program

modeling business design, along with key performance indicators transforming the model into a software architecture using pattern to drive the often-repeated aspects of the software design (where appropriate) coding the process flows or state machines searching existing assets for preexisting service implementations wrapping or re-factoring existing business function to fit them better into the service designs driven from the business model or coding any new services needed by that design

Tasks of SOA modeling program (2)

defining the data and message schemas that will be used or exchanged with services, and any schema transformations at either the business or IT level that will be needed to interoperate between mismatched services setting control flow and integrity policies on service definitions, and establishing business rules and selection conditions assembling service modules and wiring service dependencies testing assemblies and propagating them through the deployment lifecycle for test, quality assurance, and delivery

Choosing Languages

The Service Component Architecture (SCA) is integral to the programming model for SOA It is intentionally language- and technology neutral Language for a service component should be selected according to the nature of of the component. Here are examples: Java is good for expressing the logic of basic service functions. BPEL is good for expressing composition of services in the form of a process flow

Languages used in SOA

SCA is designed to accommodate the use of services built in a number of languages, including: BPEL (Business Process Execution Language) Java COBOL XML C++ Fortran RPG contemporary dynamic languages as well such as: PHP, Python, Ruby, etc SOA programming model also utilizes: WSDL (Web Services Definition Language) for describing service interface SCDL (Service Component Definition Language) for defining the service component that implements the service.

Coding Rules
For each of the programming languages supported in the SOA Foundation, SCA describes the mapping of the component model into that language This includes specific spellings in each language for interoperating with other services, and binding to the data exchanges between services.

Coding Rules (2)

Procedure is as follows: 1.code service logic 2.declare service dependencies and quality of service policies 3.invoke services when you can do so safely without temporal constraints (or if you cannot then make sure you combine your service dependencies in a local module) 4.exchange data and messages with other services using a service data object (SDO) the hard technical problems such as distributed system integration, lifecycle management, security, transactional recovery, multithreading,object caching, trace monitoring, are left to the SOA Foundation middleware

User Interaction
The User Interaction aspect of the model focuses on presentation logic. Model-View-Controller design pattern codified in Java, JFS, Portlets and Xforms is the main architectural construct used within User Interaction [Model-2]

Business Components

enables creation of basic business services within the application. is the SCA programming model for those implementation types that are relevant to coding business service components Procedure is as follows: 1.define component 2.write the business logic 3. declare (security and consistency) integrity policies.

Business Components

business component invocation occures as: 1. a result of another service making a call on your service, or 2. as a result of the occurrence of a message (or event) that youve declared an interest in The programming model supports two styles: a static, type-safe form of coding and dynamic, un-typed one Static style is safer, but you need to know all types of services and data. Dynamic is the opposite

Composition model

Is a model for those implementation types that are relevant to composition. There are several composition approaches which includes process flows and state machines. language for process flows is BPEL. language for business state machines is the State Adaptive Choreography Language (SACL) Composition is achieved by defining the logic of the business process in terms of a flow (or state transitions) over a set of other services, and then declaring those service dependencies. The system binds the actual service instances that should be used to resolve those dependencies resulting in a composition of services

Information model

concerned with accessing data used within the business process. achieved through a merger of the SDO and SCA models The SDO model includes the idea of a data access service (DAS) DAS can exist in generic form leaving it up to you to extract specific data

Invocation

Services interoperate by service calls and message exchange. Service calls can be synchronous (response right away), or asynchronous (later) Message exchanges are preferred when you care more about the message than the recipient or the sender Both are supported in SOA programming model

Design

supplements actual coding of program logic in SOA programming model It contains outer service definition (interface signature), schema of messages, dependencies with other services, integrity constraints, environmental properties. Design allows deriving service from a service template. Design aspect also covers the idea that policies are integral part of services. SOA model needs to define policies (Policies can affect other services)

Physical Architecture model

describes the main physical components deployed in your operational environment not literally physical a model of the component types and relationships that you will assemble to describe your own physical architecture.

Topology

physical architecture is centered on ESB (Enterprise Service Bus) ESB server controls the service-bus on-ramps throughout the network, and hosts any intermediations for which it is better suited than service end-points. All service requests traverse the bus, even if they dont actually flow through the ESB server.

DMZ and Gateway Server

DMZ with 2 firewall servers to prevent pass-through attack Separate service buses, one (or more) for the intranet and one for the internet, bridged with a gateway (this lets you be selective about which services are made visible to the internet) The firewall server limits the protocols and ports that are visible from outside your intranet.

Proxy Server

Can serve as a bastion host. Can also cache page fragments or other static content to improve efficiency. Can distribute workload, perform bandwidth shaping, throttling, protect against DoS, and perform in-network authentication and credential mapping. May need a real bastion if you use too many of these services

Portal Server

Hosts your interaction services. The capabilities range from basic rendering through to aggregation, visual composition, and provisioning for hi-fi devices May or may not be inside your DMZ depending on your security requirements. becomes popular to isolate all presentation logic into the DMZ.

Process Server

hosts your business process services including process flows and state machines. Can host service components that surface legacy application functions within the programming model.

Application Server

hosts business application services that may be composed by business processes or interaction services. can contain a high-speed connection directly to data access services hosted on the information integration server (since speed is crucial to support process and data interaction)

Information Integration Server

hosts data composition services. also hosts the data bus over which ETL flows operate and over which data is warehoused, and business intelligence services.

Enterprise Modernization

represents any of the remaining environments in which classic application hosting environments are being updated to render their hosted applications as business services, with visibility over the service bus.

Security Server

manages the identity management, identity federation, authorization management, the auditing system, and other integrity policies used by the rest of the SOA Foundation for protecting access to services, and to help ensure accountability of business processes.

Management Server

is responsible for monitoring the entire IT service environment. It monitors end-to-end service flows, health indicators, problem events, resource utilization metrics, and capacity trends. it administers business application policies, including updates to key performance indicators, and aggregates business and highlevel system events to report on business performance trends. It may act remotely through an agent integrated into each of the platforms it is responsible for managing.

Mobile Computing

scenarios exist where significant portions of SOA application are hosted on a laptop, PDA, smart-phone or other mobile device The devices may or may not be connected to the data center all of the time E.g. an insurance agent who travels to customers office or home, or just out into the field to sell policies or to process claims. In this case the company application is run on the mobile device and this refers to mobile computing and it is support in SOA Foundation Mobile device run applications which are similar to SOA that run online but they must be capable to operate in off-line mode, storing up transactions and data. When reattached into the network they must be able to synchronize with SOA data

SOA Management

Two sides: (a) it manages the information system that implements your business design (b) the information systems effect on your business This includes: ensures the productive and efficient use of computing resources Identifies problems and resolves them making sure the end-users are getting the performance and availability they need Etc

Three SOA Management Layers

Business Service Management provides for service level planning, business impact monitoring, and prioritization of event management Composite Application Management provides support for securing the SOA environment, flow content analysis, end-user response time monitoring, service problem diagnosis, and application trace information Resource Management enables orchestration, provisioning, infrastructure health monitoring, and event automation.

SOA Management

Provisioning the deployment environment by establishing a user registry, administrative policy and procedures, and a configuration scheme that will support the physical architecture Make sure resiliency (going back to original state) of information systems is present (due to increasing complexity of these systems) Auto-management (selfconfiguring, self-healing, self-tuning and selfprotecting) is very important in SOA, since services are distributed. It may take time to realize there is a problem if one service fails due to delays (It would be bad if you find out about problems from the users all due to delays) SOA must be able to fix itself without waiting for administrator to do it SOA monitor itself to prevent problems, adjust resource consumption, queues, etc.