1 Advanced SCA Michael Rowley, Ph.D. Director, Technology Office of the CTO April 28, 2008 TS-3765.

Slides:



Advertisements
Similar presentations
Web Service Architecture
Advertisements

Web Service Ahmed Gamal Ahmed Nile University Bioinformatics Group
SOAP.
SOAP Quang Vinh Pham Simon De Baets Université Libre de Bruxelles1.
This product includes material developed by the Globus Project ( Introduction to Grid Services and GT3.
SOA and Web Services. SOA Architecture Explaination Transport protocols - communicate between a service and a requester. Messaging layer - enables the.
Approaches to EJB Replication. Overview J2EE architecture –EJB, components, services Replication –Clustering, container, application Conclusions –Advantages.
Environmental Council of States Network Authentication and Authorization Services The Shared Security Component February 28, 2005.
Copyright © The OWASP Foundation Permission is granted to copy, distribute and/or modify this document under the terms of the OWASP License. The OWASP.
Component Patterns – Architecture and Applications with EJB copyright © 2001, MATHEMA AG Component Patterns Architecture and Applications with EJB JavaForum.
G O B E Y O N D C O N V E N T I O N WORF: Developing DB2 UDB based Web Services on a Websphere Application Server Kris Van Thillo, ABIS Training & Consulting.
Latest techniques and Applications in Interprocess Communication and Coordination Xiaoou Zhang.
Hands-On Microsoft Windows Server 2003 Administration Chapter 5 Administering File Resources.
Service Broker Lesson 11. Skills Matrix Service Broker Service Broker, provides a solution to common problems with message delivery and consistency that.
Web Services Michael Smith Alex Feldman. What is a Web Service? A Web service is a message-oriented software system designed to support inter-operable.
Getting Started with WCF Windows Communication Foundation 4.0 Development Chapter 1.
Secure Systems Research Group - FAU Web Services Standards Presented by Keiko Hashizume.
System Design/Implementation and Support for Build 2 PDS Management Council Face-to-Face Mountain View, CA Nov 30 - Dec 1, 2011 Sean Hardman.
Asynchronous Services - The key to enterprise SOA Johan Eltes Callista Enterprise AB.
Methodology and Tools for End-to-End SOA Configurations By: Fumiko satoh, Yuichi nakamura, Nirmal K. Mukhi, Michiaki Tatsubori, Kouichi ono.
1 © Talend 2014 Service Registry / WS-Policy Registry Training Slides 2014 Jan Bernhardt Zsolt Beothy-Elo
INTRODUCING SCA Byungwook Cho Nov.2007.
1 J2EE Components. 2 Application Servers relieve the programming burden for business distributed components. They provide support for system level services.
C Copyright © 2009, Oracle. All rights reserved. Appendix C: Service-Oriented Architectures.
T Network Application Frameworks and XML Web Services and WSDL Sasu Tarkoma Based on slides by Pekka Nikander.
An Introduction to Software Architecture
Module 14: WCF Send Adapters. Overview Lesson 1: Introduction to WCF Send Adapters Lesson 2: Consuming a Web Service Lesson 3: Consuming Services from.
95-843: Service Oriented Architecture 1 Master of Information System Management Service Oriented Architecture Lecture 10: Service Component Architecture.
Enterprise JavaBeans. What is EJB? l An EJB is a specialized, non-visual JavaBean that runs on a server. l EJB technology supports application development.
Message-Driven Beans and EJB Security Lesson 4B / Slide 1 of 37 J2EE Server Components Objectives In this lesson, you will learn about: Identify features.
第十四章 J2EE 入门 Introduction What is J2EE ?
Web Services Description Language CS409 Application Services Even Semester 2007.
Web Services Security Standards Overview for the Non-Specialist Hal Lockhart Office of the CTO BEA Systems.
SCA Assembly Model Anish Karmarkar – Oracle Michael Rowley – BEA.
Component frameworks Roy Kensmil. Historical trens in software development. ABSTRACT INTERACTIONS COMPONENT BUS COMPONENT GLUE THIRD-PARTY BINDING.
Web Services Based on SOA: Concepts, Technology, Design by Thomas Erl MIS 181.9: Service Oriented Architecture 2 nd Semester,
XML Web Services Architecture Siddharth Ruchandani CS 6362 – SW Architecture & Design Summer /11/05.
SOA-14: Deploying your SOA Application David Cleary Principal Software Engineer.
Random Logic l Forum.NET l Web Services Enhancements for Microsoft.NET (WSE) Forum.NET ● October 4th, 2006.
Databases JDBC (Java Database Connectivity) –Thin clients – servlet,JavaServer Pages (JSP) –Thick clients – RMI to remote databases –most recommended way.
Tuscany: a SOA framework Jeffrey Guo Accelrys, Inc.
Tu sca ny 1 The Tuscany Java SCA Runtime 20 August 2006.
SCA Bindings Simon Holdsworth Piotr Przybylski. Agenda n SCA Bindings Overview l Bindings TC Charter n Bindings l Web Services Binding l JMS Binding l.
Grid Services I - Concepts
Distribution and components. 2 What is the problem? Enterprise computing is Large scale & complex: It supports large scale and complex organisations Spanning.
Tu sca ny 1 The Tuscany Project in the Apache Incubator and The Service Component Architecture Jeremy Boynes Simon Nash 28 June 2006.
1 Policy-Enabling the SCA-based SOA
Technical Support to SOA Governance E-Government Conference May 1-2, 2008 John Salasin, Ph.D. DARPA
© FPT SOFTWARE – TRAINING MATERIAL – Internal use 04e-BM/NS/HDCV/FSOFT v2/3 JSP Application Models.
FIPA Abstract Architecture London FIPA meeting January 24-29, 2000 from: TC-A members.
SCA Assembly Model Anish Karmarkar – Oracle Michael Rowley – BEA.
Service Component Architecture (SCA) Policy TC … Face to Face Agenda – Jan 24,
AMQP, Message Broker Babu Ram Dawadi. overview Why MOM architecture? Messaging broker like RabbitMQ in brief RabbitMQ AMQP – What is it ?
Service Component Architecture Policy TC Issue 33 Capabilities.
SCA and Java n SCA provides support for multiple Java-based component implementation types l Java POJOs (implementation.java) l Spring Beans (implementation.spring)
Introduction to Active Directory
Component Patterns – Architecture and Applications with EJB copyright © 2001, MATHEMA AG Component Patterns Architecture and Applications with EJB Markus.
Introduction to EJB. What is an EJB ?  An enterprise java bean is a server-side component that encapsulates the business logic of an application. By.
Java Programming: Advanced Topics 1 Enterprise JavaBeans Chapter 14.
.NET Mobile Application Development XML Web Services.
Service Component Architecture (SCA) Policy FrameWork V1.0 Ashok Malhotra – Oracle Anish Karmarkar – Oracle David Booz - IBM …
DEVELOPING WEB SERVICES WITH JAVA DESIGN WEB SERVICE ENDPOINT.
Active Directory Domain Services (AD DS). Identity and Access (IDA) – An IDA infrastructure should: Store information about users, groups, computers and.
# # 0089CB # 00283C HEXRGB # COLOUR PALETTE TEXT COLOUR HEXRGB # FFFFFF 255 # # BFBFBF.
Business Process Execution Language (BPEL) Pınar Tekin.
1 Introduction to Service Component Architecture Feature Pack for WebSphere Application Server & SCA Tooling in RAD Mike Edwards and Sara Mitchell - IBM.
An Introduction to Software Architecture
Knowledge Byte In this section, you will learn about:
Presentation transcript:

1 Advanced SCA Michael Rowley, Ph.D. Director, Technology Office of the CTO April 28, 2008 TS-3765

Outline Quick review of SCA Advanced Construction Techniques  Local-Only Services  Conversations  Callbacks  Components created using Spring Advanced Assembly Techniques  Autowire  Include  Constraining Types Packaging and Deployment Configuring Infrastructure Services using Policy

Goals of the Service Component Architecture (SCA) A development and deployment model for SOA  Service-based models for: Construction Assembly Deployment  In a heterogeneous environment of multiple languages multiple service access methods

Construction – Component Implementation Provides code necessary to execute component Examples:  Java TM class  BPEL process definition  C++ class  SCA Composite May be used by multiple components Declares SCA visible features  Services  References  Properties  Required Policy Intents Service and references declarations are typed by interface  Interface may be Remotable or Local-Only

Construction with public interface AccountService{ public AccountReport getAccountReport(String customerID); } public class AccountServiceImpl implements AccountService private String currency = private AccountUpgradeService private StockQuoteService stockQuoteService; public AccountReport getAccountReport(String customerID) { … } … }

Construction with BPEL

Service Interfaces Service Interfaces in multiple interface languages  E.g. WSDL 1.1, WSDL 2.0, Java, C++, etc. All interfaces used by remotable interfaces must be translatable into WSDL 1.1  No translation need actually happen Advanced (SCA-Specific) interface extensions  Local-Only vs. Remotable Interfaces  Conversational Interfaces Session identifying information will be sent in headers  Bi-Directional Intefaces Interface with companion callback interface

Assembly – Composite

SCA Deployment Components are deployed into an SCA Domain  Represents a region of configuration and administrative control  In general an SCA run-time is distributed and heterogeneous  Defines the scope of what can be connected by SCA wires Final overrides made at deployment time  Bindings and endpoint URIs for published services  Bindings and EPRs of external services  Properties  Concrete policy sets  Similar goals to WL Deployment Plans Simplifications when within one SCA Domain  SCA wiring used for communication  No binding necessary  Required runtime capabilities specified with high-level “intent” statements, not complete policy statements

Outline Quick review of SCA Advanced Construction Techniques  Local-Only Services  Conversations  Callbacks  Components created using Spring Advanced Assembly Techniques  Autowire  Include  Constraining Types Packaging and Deployment Configuring Infrastructure Services using Policy

Local & Remotable Services Local-Only Services  Fine-grained, tightly coupled interfaces  Interface may be language specific (e.g. Java or C++)  Parameters & return values by- reference  Client must be local (same address space) Remotable Services  Coarse-grained, loosely coupled interfaces  Interface must be representable with WSDL (possibly generated)  Parameters & return values by-value  Client may be remote SCA promotes coarse-grained services by supporting tightly-coupled assembly in addition to loosely-coupled assembly. The term “service” is possibly confusing for local-only services, but, other than the differences listed above, they are treated identically.

Conversational Services Support for long-running conversations (often bi-directional) Correlation information not specified in message body (i.e. not in parameters) Example: ۤ package com.bigbank; ۤ ۤ public interface LoanService { ۤ public void apply(LoanApplication application); ۤ public void changePoints(double points); ۤ public String getLoanStatus(); ۤ public void cancelApplication(); ۤ } Conversation protocol specified by Policy  Eg. WS-Context, WS-ReliableMessaging, WS-Conversation, JMS Correlation Header, means no further operations will be called.  Conversations can also end by timing out, with a timeout possibly specified in days.

Conversation Lifetimes Conversations start on the client side when to a conversational service is injected; or A call is made to CompositeContext.getServiceReference and then a method of the service is called. The conversation ends when: operation called called Server’s conversation lifetime timeout occurs Client calls Conversation.end() A non-business exception is thrown by a conversational operation

Scopes Available in Java and C++ implementation types Infrastructure instance management  Persist appropriately and route requests to the right instances Different lifetime & instance granularity:  Composite – One per domain (semantically)  Process – One per runtime process (e.g. JVM) (not yet part of the spec)  Conversation – One per client instance  Request – One while handling a remote request  Stateless – New every time Initialization hooks for instance creation and destruction  At the beginning and end of the scope, respectively  Stateless is different from JavaEE stateless session beans, which are initialized at server startup, not on every call.

LoanService with Conversational Scope ۤ public class LoanServiceImpl implements LoanService { ۤ private String status ; ۤ public void apply(LoanApplication application) { ۤ … ۤ status = “Not Yet Approved”; ۤ } ۤ public String getLoanStatus() { ۤ return status; ۤ } ۤ … ۤ }

APIs To Help When Not Using Conversational Scope public interface ComponentContext { ServiceReference getServiceReference(String referenceName); … } public interface RequestContext { ServiceReference getServiceReference(); … } public interface ServiceReference { Conversation getConversation(); Object getCallbackID(); Object getConversationID(); void setConversationID(Object conversationId); void setCallbackID(Object callbackID); Object getCallback(); void setCallback(Object callback); … }

LoanService with Stateless Scope ۤ public class LoanServiceImpl implements LoanService { private RequestContext request; ۤ … ۤ public void apply(LoanApplication application) { ۤ … ۤ String applicationID = requestContext.getConversationID(); application.setStatus(“Not Yet Approved”); ۤ persistenceHelper.store(approvalID, application); ۤ } ۤ public String getStatus() { ۤ String approvalID = requestContext.getConversationID(); ۤ Application application = persistenceHelper.find(approvalID); ۤ return application.getStatus(); ۤ } ۤ … ۤ }

Callbacks Bidirectional interfaces have one interface for outbound, and a second interface that should be implemented by clients. ۤ public interface LoanApproval { ۤ public void approve(LoanApplication application); ۤ } public interface ApprovalCallback { ۤ public void answer(String approval); ۤ } ● AccountData ● Service ● Component LoanService Approver Approve Answer

Conversational Callback Client ۤ public class LoanServiceImpl implements LoanService, ApprovalCallback { ۤ protected LoanApproval approver; ۤ protected String status ; ۤ public void apply(LoanApplication application) { ۤ … ۤ status = “Not Yet Approved”; ۤ approver.approve(application); ۤ } ۤ public String getLoanStatus() { ۤ return status; ۤ } ۤ public String answer(String approval) { ۤ return status = approval; ۤ } ۤ … ۤ }

Stateless Callback Client If the client is stateless, then the callback operation will go to a new (or pooled) instance.  The client instance cannot maintain state related to the callback.  Must store & retrieve state explicitly. ۤ public class LoanServiceImpl implements LoanService, ApprovalCallback { private RequestContext request; protected ServiceReference approver; ۤ … ۤ public void apply(LoanApplication application) { ۤ String applicationID = requestContext.getConversationID(); application.setStatus(“Not Yet Approved”); ۤ persistenceHelper.store(approvalID, application); ۤ approver.getService().approve(application); ۤ String approvalID = approver.getCallbackID(); ۤ persistenceHelper.store(approvalID, application); ۤ } ۤ public String answer(String approval) { ۤ String approvalID = requestContext.getCallbackID(); ۤ Application application = persistenceHelper.find(approvalID); ۤ application.setStatus(approval); ۤ pesistenceHelper.store(application); ۤ } ۤ … ۤ }

Constructing Components with Spring A Spring Application Context defines a composite  Usable as the implementation of a coarse-grained component in SCA SCA resolves wires from Spring beans to SCA components SCA provides policies and bindings for services implemented in Spring

Two Spring Modules in one SCA Domain SCA Domain Application Context A Bean X Declared Service Reference As A Bean Bean Y Use of Spring Module A Use of Spring Module B Spring Application Context B Bean Z Declared Service Bean W Service Binding Spring App

Spring Context A - XML File ۤ ۤ timeout ۤ

Use of Spring Composite ۤ ۤ <implementation.spring module=“SpringApplicationA” ۤ location=“archive/path”/> ۤ ۤ SpringComponent2 ۤ ۤ <implementation.spring module=“SpringApplicationB” ۤ bundle=“archive2/path”/> ۤ

Outline Quick review of SCA Advanced Construction Techniques  Local-Only Services  Conversations  Callbacks  Components created using Spring Advanced Assembly Techniques  Autowire  Include  Constraining Types Packaging and Deployment Configuring Infrastructure Services using Policy

n Allows component references to be wired to component services automatically (without explicit wires) n Matches references to services based on compatible interfaces, bindings, policy intents/sets Payments Component Payment Service AccountsComposite External Banking Service Accounts Ledger Component Product Pricing Component Customer Account Component AutoWiring

Inclusion X Service A B C Y Ref2 B C Ref1 Includes X Service A C Ref1 B Ref2

n Inclusion n Recursive composition n Implementation reuse through configurable components n Reusing composite configuration through composite-level references and properties. n Reusable bindings (See JMS binding spec) Reuse in SCA

n constrainingType l Implementation independent l Specifies the shape -- constraints in terms of services/references/properties l composites, components, componentType and implementations can be constrained using the “constrainingType” attribute l Allows an architect to specify constrainingTypes which can be used by developers as a template l SCA provides runtime validation of artifacts with its constrainingType Top-Down Design: ConstrainingType

EURO constrainingType Example

Outline Quick review of SCA Advanced Construction Techniques  Local-Only Services  Conversations  Callbacks  Components created using Spring Advanced Assembly Techniques  Autowire  Include  Constraining Types Packaging and Deployment Configuring Infrastructure Services using Policy

Packaging and Deployment: Domains Composites deployed, configured into SCA Domain  Defines the boundary of visibility for SCA  Typically an area of functionality controlled by single organization/division E.g.: accounts Configuration represented by virtual composite  potentially distributed across a network of nodes  contains components, services, references, wires  configured using composites Composites make deployment simpler  individual composites created, deployed independently  may contain only wires or components or externally provided services or references Abstract services provided for management of the domain

Deployment: Domain-Level Composite Composite Y Component B A Composite A Composite B Service Composite XComposite Z implementation Wire Domain Reference

Packaging and Deployment: Contributions Contributions hold artifacts available for use in the Domain Package containing artifacts necessary for SCA  SCA defined artifacts E.g.: composites, constrainingType, etc  Non-SCA defined artifacts E.g.: WSDL, XML schema, Java classes, object code etc Packaging must be hierarchical Metadata included in the “META-INF” directory * Interoperable packaging format: ZIP Other formats possible: filesystem directory, OSGi bundle, JAR file

SCA Runtime Example SCA PHP Container Assigned to be hosted by SCA Java container Assigned to be hosted by SCA CPP container Runtime Topology Deployment Mapping Service Compositions SCA Domain bigbank.accountmanagement bigbank.stockquote SCA JEE ContainersSCA CPP Containers … SCA Java Containers SCA BPEL Container

Outline Quick review of SCA Advanced Construction Techniques  Local-Only Services  Conversations  Callbacks  Components created using Spring Advanced Assembly Techniques  Autowire  Include  Constraining Types Packaging and Deployment Configuring Infrastructure Services using Policy

Generalizing Policy WS-Policy is sometimes used for configuration but is not designed for it WS-Policy is for external clients  Must provide all details, so is necessarily complex Runtime configuration needs those details plus additional information  E.g. key store information, logging targets, etc SCA Policy is for configuration But, it can use defaults & reuse not available to external clients.

SCA Policy SCA allows a few acceptable configurations to be created and used throughout A policy intent is named for some capability, e.g. “confidentiality” Each binding has PolicySets for how that policy intent is achieved.  E.g. Binding.WS has WS-Policy assertions that configure “confidentiality” with encryption Service and references may require the capability by just naming it: ۤ <service name="myService" type="myType" ۤ requires="confidentiality"…

Policy Administrator Policy Administrator defines the intent: ۤ ۤ 3 rd parties should be unable to read the messages ۤ …and policySets that achieve it ۤ ۤ... Standard WS-Policy ۤ ۤ </policySet ۤ

Attaching Profiles and mapping to PolicySets Module Profile Interaction Policy Implementation Policy B Module Component service Profile Authentication messageIntegrity messageIntegrity exactlyOnce” Policies locate WS-Policy Binding Web Services JCA JMS

Qualified Intents Developers or assemblers may need to specify some aspect of how the intent is provided  Without specify everything, or even the binding to use Example: Confidentiality could be provided with  Message-level encryption ۤ <service name="myService" type="myType" ۤ requires="confidentiality.message"…  Transport-level encryption ۤ <service name="myService" type="myType" ۤ requires="confidentiality.transport"… An intent named A.B means:  A is a Qualifiable Intent  B is a Qualifier – one way of achieving A Further Qualification is allowed:  Requires=“confidentiality.message.body”

Profile Intents Shortcut for specifying a group of other intents Expands into a list of other intents <intent name="sca:messageProtection" constrains="sca:binding" requires="sca:confidentiality sca:integrity"> Protect messages from unauthorized reading or modification.

Intents Provided by Bindings The binding technology can satisfy intents  E.g. JMS supports reliable messaging Binding Type declarations specify intents satisfied <bindingType type=“sca:binding.jms" mayProvide=“sca:atLeastOnce sca:atMostOnce sca:ordered"? alwaysProvides = = the element name used for the = intents that are provided only if the service or reference requires = intents that are always provided The intents provided by a binding are vendor specific.

Configuring Infrastructure with Intents Infrastructure provides configurable capabilities for communication:  Authentication  Encryption  Non-Repudiation  Reliable Messaging …as well as for hosting components  Authorization  Transactions  Monitoring & Logging Each is represented with intents, sometimes qualified

Reliability Intents atLeastOnce  Message MUST be delivered at least once. Duplicates are allowed. atMostOnce  Message MAY be delivered. Duplicates are NOT allowed. exactlyOnce  A profile intent that expands to “atLeastOnce atMostOnce” Ordered  For each sending component, the receiver MUST receive messages in the order they were sent.  No ordering is required between messages sent by different senders

Security Intents authentication – Client must reliably identify the security subject (e.g. username / password) confidentiality – Prevent unauthorized reading of message traffic (e.g. encryption) integrity – Prevent unauthorized modification of messages (e.g. signing) Each intent supports the following qualifiers: transport – guarantee it at the transport layer. message – guarantee it for the message (end-to-end)

Transaction Implementation Intents managedTransaction – Some form of managed transaction must be used. managedTransaction.global – A global transaction should be joined or started managedTransaction.local – Local transactions for each resource should be used.  Committed when the remotable method completes  Multiple resources may be used, but no atomicity guarantee noManagedTransaction – No managed transaction should be used.  App code will demarcate transactions,  or resource will commit after each method called on the it (absent) – No requirement. Deployer or vendor runtime may choose any of the above strategies.

OneWay Transaction Intents TransactedOneWay  Send only at commit  Receive is successful only if commit is successful ImmediateOneWay  Message sent immediately, not at commit  Enables a send and corresponding receive within one txn

Transaction Interaction Intents propagatesTransaction – Join the transaction of the client.  Transactional clients can depend on atomicity. suspendsTransaction – Don’t join any transactions.  Suspend any existing transaction before making the call on this service or reference. Not relevant for OneWay, as txn is never propagated on OneWay

Other Intents SOAP –The SOAP messaging model must be used by the binding. Without a qualifier, any version may be used. Qualifiers:  SOAP.1_1 – Must use SOAP v1.1  SOAP.1_2 – Must use SOAP v1.2 JMS – The binding must support JMS API  Used to limit the bindings chosen when the sender or receiver needs to use the JMS API NoListener – For references only. The must not accept new inbound connections. Use a backchannel or polling. BP.1_1 – Binding must conform to WS-I Basic Profile version 1.1. Conversational – The binding must be able to generate and send conversation IDs.

SCA Policy Assertions for Authorization A few policy assertions are also standardized in SCA Policy assertions are used in Policy Sets Allowed roles are specified with one of the following: Security Identity is specified with the runAs assertion  By default, the service runs with the identity of the caller.