SOA Programming Model and Physical Architecture Model

1. SOA Programming Model and Physical Architecture Model Loutfouz Zaman (Shumon)

2. 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)

3. 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). It’s called Progressive Disclosure

4. 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

5. 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)

6. Three main concepts • Service components implement services (regardless of whether they are interaction services,process services, business application services, information services, accessservices or partner services) • Data is exchanged between services as Service data • Services are invoked over a service bus

7. Service Components • a technology and language-neutralrepresentation 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 encapsulatedwithin a service component (presentation, business or data logic) • are hosted in a service container – an equally abstract representation of the underlying implementation technology container.

8. Service Data • a language and technology-independentrepresentation 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)

9. Service Bus • is meant to be entirely transparent to theprogramming 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.

10. Purpose of roles • the purpose of distinguishing roles is to identify the expectations of responsibility, skills, and tools that arerelevant to each of these roles. • differentiating roles may or maynot require differentiating the individuals who have those roles. • it is likely thata 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 largeorganization.

11. Roles • Business Analyst - responsible for knowing the businessprocesses in the design and capturing them in amodel 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.

12. 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.

13. 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)

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

15. Roles…(5) • Enterprise developer - a specialist in legacy application functions,languages and technologies • responsible forassisting 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.

16. Roles…(6) • Enterprise Architect oversees and conducts the entire process. • Ensures consistency across each role’s tasks • Tries to balance the creation of implementationartifacts (representing the business design) against the constraints, preferences, and legacy capabilities.

17. 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

18. Tasks of SOA modeling program • modeling business design, along with key performanceindicators • transforming the model into a software architecture using pattern to drive the often-repeated aspects of thesoftware design (where appropriate) • coding the process flows or state machines • searching existing assets for preexisting serviceimplementations • wrapping or re-factoring existing business function to fit them betterinto the service designs driven from the business model or codingany new services needed by that design

19. Tasks of SOA modeling program (2) • defining the data and message schemas that will be used orexchanged with services, and any schema transformations ateither the business or IT level that will be needed to interoperatebetween mismatched services • setting control flow and integrity policies on service definitions,and establishing business rules and selection conditions • assembling service modules and wiring servicedependencies • testing assemblies and propagating them through thedeployment lifecycle for test, quality assurance, and delivery

20. Choosing Languages • The Service Component Architecture (SCA) is integral to theprogramming model for SOA • It is intentionally language- and technology neutral • Language for a service component should be selected according to the nature ofof 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

21. Languages used in SOA • SCA is designed to accommodate the use of services built in a number oflanguages, 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.

22. 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 withother services, and binding to the data exchanges between services.

23. Coding Rules (2) • Procedure is as follows: • 1.code service logic • 2.declare service dependencies and quality of servicepolicies • 3.invoke services when you can do so safely without temporalconstraints (or if you cannot then make sure you combine your servicedependencies 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, multi-threading,object caching, trace monitoring, are left to the SOA Foundation middleware

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

25. Business Components • enables creation of basicbusiness services within the application. • is the SCA programming model for thoseimplementation types that are relevant to coding business servicecomponents • Procedure is as follows: • 1.define component • 2.write the business logic • 3. declare (security and consistency) integrity policies.

26. Business Components • business component invocation occures as: • 1. a result of anotherservice making a call on your service, or • 2. as a resultof the occurrence of a message (or event) that you’ve 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

27. 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

28. Information model • concerned with accessingdata used within the business process. • achieved through a merger ofthe SDO and SCA models • The SDO model includes the idea of a data accessservice (DAS) • DAS can exist in generic form – leaving it up to you to extract specific data

29. 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

30. Design • supplements actual coding of programlogic in SOA programming model • It contains outerservice 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)

31. Physical Architecture model • describes the main physical componentsdeployed in your operational environment • not literally physical • a modelof the component types and relationshipsthat you will assemble to describe your own physical architecture.

32. Topology • physical architecture is centered on ESB (Enterprise Service Bus) • ESB server controlsthe service-bus on-ramps throughout the network,and hosts any intermediationsfor which it is better suited than service end-points. • All servicerequests traverse the bus, even if they don’t actually flow through the ESBserver.

33. 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 forthe internet, bridged with a gateway(this lets you beselective about which services are made visible to the internet) • The firewall server limits the protocols and ports that are visible from outsideyour intranet.

34. Proxy Server • Can serve as a bastion host. • Can also cache pagefragments or other static content to improve efficiency. • Can distributeworkload, perform bandwidth shaping, throttling, protect against DoS, and perform in-network authentication and credentialmapping. • May need a real bastion if you use too many of these services

35. Portal Server • Hosts your interaction services. • The capabilities range from basic rendering through to aggregation, visualcomposition, and provisioning for hi-fi devices • May or may not be inside your DMZ dependingon your security requirements. • becomes popular to isolateall presentation logic into the DMZ.

36. Process Server • hosts your business process services including process flows and state machines. • Can host servicecomponents that surface legacy application functions within theprogramming model.

37. Application Server • hosts business application services that may becomposed by business processes or interaction services. • can contain a high-speed connection directly to data accessservices hosted on the information integration server (since speed is crucial to support process and data interaction)

38. Information Integration Server • hosts data composition services. • also hoststhe data bus over which ETL flows operate andover which data iswarehoused, and business intelligence services.

39. Enterprise Modernization • represents any of the remaining environments inwhich classic application hosting environments are being updated to rendertheir hosted applications as business services, with visibility over the servicebus.

40. Security Server • manages the identity management, identity federation,authorization management, the auditing system, and other integrity policiesused by the rest of the SOA Foundation for protecting access to services, andto help ensure accountability of business processes.

41. Management Server • is responsible for monitoring the entire IT serviceenvironment. • It monitors end-to-end service flows, health indicators,problem events, resource utilization metrics, and capacity trends. • it administers business application policies, includingupdates to key performance indicators, and aggregates business and highlevelsystem events to report on business performance trends. • It may act remotely through an agent integrated into eachof the platforms it is responsible for managing.

42. Mobile Computing • scenarios exist wheresignificant portions of SOA application are hosted on a laptop, PDA,smart-phone or other mobile device • The devices may or may not beconnected to the data center all of the time • E.g. an insurance agent who travels tocustomers’ office or home, or just out into the field to sell policies or toprocess 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 on-line 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

43. SOA Management • Two sides: • (a) it manages the information system thatimplements your business design • (b) the information system’seffect 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…

44. 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 theSOA environment, flow content analysis, end-user response timemonitoring, service problem diagnosis, andapplication trace information • Resource Management enables orchestration, provisioning,infrastructure health monitoring, and event automation.

45. SOA Management • Provisioning the deployment environment by establishing a user registry, administrative policyand procedures, and a configuration scheme that will support the physicalarchitecture • 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 self-protecting) 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.