Upload
zubin67
View
338
Download
3
Embed Size (px)
DESCRIPTION
Citation preview
SOA for Realהמוקשים והקשיים שחוויים בפרויקטי
SOAלירן זילכה
ל משותף"מנכ
Aluna
Aluna
Israel’s leading Java/JavaEE and SOA consulting company
Customers:
Agenda
SOA Architecture
SOA pitfalls
Using Services
DB
CCI CCI CCI
ERP CRM
Service Service Service
Registry
1
register
Consumer
SOAP SOAP SOAP
XML XML XML
3 invoke
2
Discover and/or Bind
Policies
Components To Services
Requires a client library
Client / Server
Extendable
Stateless
Fast
Small to medium granularity
Loose coupling via
◦ Message exchanges
◦ Policies
Peer-to-peer
Composable
Context independent
Some overhead
Medium to coarse granularity
BUSINESS DOMAIN
Business
Service #1
Business
Service #2 Business
Service
#4
Business
Service
#5
IT DOMAIN
Business
Service #4
Business
Service #3
Business
Service
#6 Business
Service
#5
Business Process #2
Business
Service #3
Business
Service
#4 Business
Service
#5
Business
Service #3
Business
Service #7
Business Process #1
Re-usable Business
Services
IT Service
#1
IT Service
#2
IT Service
#3
Business Service #3
IT Service
#2
IT Service
#4
IT Service
#3
Business Service #5
IT Service
#2
IT Service
#3
Re-usable IT
Services
SOA Pitfalls
SOA Misconceptions
http://www.manning.com/rotem/
Web Services
Is this technology actually delivers?
Many technological problems:◦ Target client language – effects API
Checked exceptions in C#
Overloading
Documentation/Metadata
Web Services – Current Solutions
Tools that make sure you fit the spec
Extend wsdl.exe, wsgen.exe◦ To enable R&D naming conventions
Check WSDL 2.0◦ No more MessageType
◦ Tag names changes
◦ Otherwise, they would have called it WSDL 1.2
Web Services
Performance
Web Services – Current Solutions
Performance keeps improving
XML level◦ Make sure your framework is based on pull-parsing
Transport level◦ Use other transports – Messaging, Binary
◦ Use HTTP, but use keepalive
Web Services
Advanced specs:◦ Transactions?
◦ Addressing?
◦ Security?
Participants & Transaction aware Web services
Why WS-Security?
We are going to “virtualize” security
If you understand Code Access Security then you understand where security is heading in terms of Web Services◦ WS-Security conceptualizes the same idea of CAS
◦ “This message carries certain rights…”
Identity, authentication, authorization…
What is security?
Technical◦ Encryption
◦ Signatures
◦ …
Non-Technical◦ Policies
◦ Trust
◦ …
Composition
Processing
How is security implemented today?
Point-to-Point◦ Channel
SSL, IPSec
◦ Entry Point
ACLs and Roles
End-to-End◦ Message Based
XML Web Services
Point-to-Point Security
Cons◦ Not implemented at the messaging layer
◦ Does not enforce up stream security
◦ Do not natively support non-repudiation
◦ Binds you to a specific transport protocol
◦ Requires additional management
Pros◦ Broad adoption
◦ Can be implemented in a standards based manner today
End-to-End Security
Cons◦ Standards are evolving and will be delivered incrementally
Pros◦ Is implemented at the messaging layer
◦ Enables heterogeneous architecture
◦ Supports non-repudiation
◦ Can be independent of transport
WS-Security
WS-Security describes enhancements to SOAP messaging to provide quality of protection through message integrity, message confidentiality, and single message authentication
WS-Security
A specification for proposed SOAP extensions to be used when building secure Web services◦ Supercedes the following specifications
SOAP-SEC
Microsoft’s WS-Security, WS-License
IBM’s security token and encryption
WS-Security
What◦ Enhancements to SOAP
◦ Quality of protection
Integrity
Confidentiality
Authentication
◦ Token Association
◦ Token Encoding
◦ Designed to be composed with other Web service protocols
◦ Is not a complete security solution
WS-Security Token Elements
UsernameToken Element◦ A means of proving a username and optional password information
BinarySecurityToken Element◦ A means of including x.509 and Kerberos tickets
SecurityTokenReference Element◦ A means of providing a set of claims the reside “somewhere”
WS-Security
Goals◦ Single message security language
◦ Flexible; does not define explicit security protocols
Requirements◦ Multiple security tokens for authentication and authorization
◦ Multiple trust domains
◦ Multiple encryption technologies
◦ End-to-end message-level security
WS-Addressing
Using SOAP without HTTP
Using A-Synch web services
Goal of WS-Addressing
Aim is to make Web Services to support :◦ A wide range of transport protocols
◦ Asynchronous communication
◦ Dynamic end point addressing
A small set of tags is defined
Transport Protocol Neutral SOAP
The type of the
message being
conveyed is SOAP
Host URI
SOAP Action
Transport Protocol Neutral SOAP(II)
Asynchronous Web Services
WSDL defines one-way, request-response, solicit response, and notification messaging behaviours
Normally, when a response is made, it is assumed that this response will be conveyed by the already opened HTTP Channel.
Therefore currently there is no standard support to achieve asynchronous communication between Web Services
WS-Addressing adds <MessageID>, <From>, <ReplyTo>, <FaultTo>, <RelatedTo>
Asynchronous Web Services (II)
current message has id “uuid:someid”
and it is related with another message
that has id “uuid:someotherid” and the
type of the relationship is “Reply”
The address of the sender of the
message, the addresses for return
reply or fault messages are given
Endpoints
<From>, <ReplyTo>, <FaultTo> tags convey an “EndpointReference”
Endpoint is any addressable resource to which SOAP message can be sent (Web Service client or application, a SOAP router or any SOAP aware entity
The most logical way to include endpoints is to use WSDL “Service” element, however WSDL does not allow extensibility of this element, therefore EndpointReference is defined.
EndpointReference may be used in WSDL
WS-Addressing defines two constructs to conveyinformation that is typically provided by transport protocols and messaging systems:
◦ Endpoint Reference (provides dynamic endpoints)
◦ Message Information Header (provides asynchronous transport neutral comm., )
WS Addressing Constructs
Fault Codes
Some fault codes are defined (the same logic in HTTP, i.e. 404 file not found)
Fault schema of SOAP is extended
Defined faults:◦ Endpoint Unavailable,
◦ Action Not Supported,
◦ Destination Unreachable,
◦ Message Information Header Required,
◦ Invalid Message Information Header
Web Services
QA◦ How do we implement it?
◦ Unit or integration testing?
Who is in charge?
◦ Support matrix:
.NET frameworks – WCF, WSE 2.0…
Java frameworks – AXIS1, AXIS2, JAX-RPC, JAX-WS
Web Services – Current Solutions
Automated testing tools:◦ SOATest
◦ Actional
Open source testing tools:◦ Web Service Studio
◦ The Grinder
◦ SoapUI
BPEL
When do we use BPEL and when do we use the ESB?
BPEL – Current Solutions
BPEL is used for business processes
ESB is used to move information
Is that helpful in anyway?
BPEL
Where is the human decisions in the process?
BPEL – Current Solutions
BPEL4People was handed to OASIS (Jan, 2008)
Meanwhile – use extensions
http://xml.coverpages.org/bpel4people.html
ESB
How many ESBs do you have in your organization?
Are they talking to one another?
What to do inside or outside the ESB?
ESB – Current Solutions
Most ESBs are based on fast messaging and JavaEE Application Servers
The ESB is used to deliver thousands of messages a second. How much code do you want to place in it?
ESB
How do we connect ESB to BPEL?
What else can be placed inside the ESB?◦ Runtime governance?
ESB – Current Solutions
JBI will become a spec◦ Take OpenESB for example
In the mean time…
ESB
BPEL
JBI
Java Business Integration (JBI)
Extends J2EE and J2SE with business integration SPIs (JSR 208).
SPIs enable the creation of a Java business integration environment for specifications such as WSCI, BPEL4WS and the W3C Choreography Working Group.
45
Java Business Integration (JBI)
Employs concepts similar to J2EE to extend application packaging and deployment functionality to include JBI Components.
JBI Components are an open-ended class of components that are based on JBI abstract business process metadata.
http://jcp.org/en/jsr/detail?id=208
46
JBI Roles Integration Architect. This user designs the overall
approach to solving integration problems. This includes selecting JBI components used to provide connectivity and business logic.
Integration Technologist. This user devises the particular services needed to solve an integration problem and configures a JBI system to integrate those services.
System Administrator. This user installs, configures, monitors, and tunes the JBI system so that it provides the designed integration services.
JBI Component Developer. JBI components can be created by users or third parties. In either case, the developer of JBI plug-ins must provide Java components that conform to the JBI specification.
47
Steps In Developing A Service Creation of the service: A developer creates services either from
scratch or from existing implementations of services. Packed into Service Units.
Orchestration of the service (optional step): Then either the developer or the integration architect/technologist composes the services using an orchestration engine.
Creation of the Service Assembly: The developer or integration architect/technologist then determines how to provide access to these internal services, as well as to any external services on which they depend. I.e., Binding Components must be selected and then configured for both inbound and outbound access. After configuration, a Service Unit must be created for each required Binding Component. The various Service Units for the Service Engines and Binding Components are then packaged into a Service Assembly.
Deployment of the Service Assembly.
48
JBI CoreServices
Normalized Message ServiceInstallationDeploymentManagement
Component Registry
System
Managem
ent
Admin.
Console
Logger
Discovery &
Deployment
Orchestration(BPEL)
WSDL
Transformation(XSLT)
WSDL
J2EE
WSDL
Filesystem
WSDL
JMS
WSDL
WS-I Basic +Basic Security
WSDL
Other Bindings
WSDL
Other Service Engines
WSDL
Service1
Service2
Service3
SOAP SOAP JMS
WSDL WSDL WSDL
J2SE/J2EE
Application Element Artifact
Service Orchestration BPEL
Data Transformation XSLT
Service 1 WSDL
Service 2 WSDL
Service 3 WSDL
JBI CoreServices
InstallationDeploymentManagement
Component Registry
System
Managem
ent
Admin.
Console
Logger
Discovery &
Deployment
Orchestration(BPEL)
WSDL
Transformation(XSLT)
WSDL
J2EE
WSDL
Filesystem
WSDL
JMS
WSDL
WS-I Basic +Basic Security
WSDL
Other Bindings
WSDL
Other Service Engines
WSDL
Service1
Service2
Service3
SOAP SOAP JMS
WSDL WSDL WSDL
J2SE/J2EE
SOA Composite App Descriptor
ESB
Can we bundle an ESB inside our product?◦ Most ESBs are point-to-point based
◦ Adding a service requires updating the ESB itself
ESB – Current Solutions
Extending the ESB in code
Writing dispatcher code inside the ESB◦ See the Router pattern in the next presentation
Governance
Ever heard of someone who actually did it?
Governance – Current Solutions
New concept, but still◦ You must have governance
◦ Know what services you have
◦ Make sure they are documented, fit company procedures, etc
Currency Service
A scenario on the importance of SOA governance
Finance
LegalSales
PurchasingOrder
Fulfillment
1. All groups plan
a re-usable
currency service
2. Service defined
that meets
everyone’s needs
3. Service enabled
to be available
to all LOBs
4. Success metrics
defined, monitored
to confirm service
scalability
14 Critical Processes That Constitute an Effective SOA Governance Model Implementation
Service
Planning
Service
Modeling
Service
Implementation
Service
Management
Define Service
Focus Process
Assemble
Services Process
Deploy Services
Process
Test Services
Process
Design Services
Process
Manage Service
Levels Process
Manage Service
Security Process
Manage Service
Change Process
Manage Quality of
Service Process
Specify Services
Process
Realize Services
Process
Identify Services
Process
Define Service
Funding Process
Identify Service
Owners Process
By effectively establishing governance
mechanisms in these 14 areas, clients
can address these common challenges:
Establishing decision rights
Defining high value business services
Managing the lifecycle of assets
Measuring effectiveness
Service Lifecycle Management is essential in the realization of SOA Governance
Infrastructure and
Management
In Support of SOA
Monitor and control
operational policies
Service Development
and Delivery
Management
Enforce, execute, automate
process and policies
SOA Governance Method
Establish Process and Policies
SOA Governance
Service Lifecycle Management
SOA Governance Method
Establish the Governance Need• Document and validate business strategy for SOA and IT
• Assess current IT and SOA capabilities
• Define/Refine SOA vision and strategy
• Review current Governance capabilities and arrangements
• Layout Governance plan
Define the Governance Approach• Define/modify Governance Processes
• Design policies and enforcement mechanisms
• Identify success factors, mechanisms
• Identify owners and funding model
• Charter/refine SOA Center of Excellence
• Design Governance IT infrastructure
Deploy the Governance Model Incrementally• Deploy Governance mechanisms
• Deploy Governance IT infrastructure
• Educate and deploy on expected behaviors and practices
• Deploy policies
Monitor and Manage the Governance Processes • Monitor compliance with policies
• Monitor compliance with governance arrangements
• Monitor IT effectiveness metrics
Q&A