Transcript JavaZone - Why I hate SOA

SOA
$$$$
Why I hate
(the hype about) SOA
What is the SOA business case?
Prelude – what is wrong with this code?
public Collection findByPattern(String namePattern)
throws SQLException {
Connection conn = DriverManager.getConnection(this.url,
this.username, this.password);
Statement stmt = conn.createStatement();
ResultSet rs = stmt.executeQuery(
"SELECT name FROM name_table WHERE name like '"
+ namePattern + "'");
Collection result = new ArrayList();
while (rs.next()) {
result.add(rs.getString(1));
}
conn.close();
return result;
}
Summary!
• Use connection pooling!
• Avoid SQL injection!
• Don’t leak the bloody
connections!
Every time you leak a connection…
God kills a kitten.
Please: Think of the kitten!
Correct code!
public Collection findByPattern(String namePattern)
{
String query =
"SELECT name FROM name_table WHERE name like
?";
Object[] params = new Object[] { namePattern };
return jdbcTemplate.query(query, params, new
RowMapper() {
public Object mapRow(ResultSet rs, int
rowNum)
throws SQLException {
return rs.getString(1);
}
});
}
Now: To the agenda of the day!
• What is SOA?
• Overdesign
• SOA promises
– Integration
– Orchestration
– Reuse
• BBS architecture
• Lessons learned
Is SOA important?
• “Gartner projects that ‘by 2008, more than 75
percent of then-current application packages either
will be natively SOA or will expose SOA interfaces
through a wrapping layer of interfaces.’ ”
[InformationWeek]
• The next (current) gold rush is in B2B (do I address
this?)
What is SOA?
• SOA is ”A collection of Services that communicate
with each other” [Cryer.com]
• ”[SOA] is an integrated software infrastructure and
design approach, leveraging Web computing
standards, for delivering business functions as
shared and reusable services.” [sun]
• ”SOA is web services” [unattributed]
• ”blah, blah,blah, SOA is described, asynchronous,
remote, loosly coupled, orchistrated, standardbased...” [someone fairly smart]
• Loose coupling
Fowler on SOA
“I've heard people say the nice thing about SOA is
that it separates data from process,
that it combines data and process,
that it uses web standards,
that it's independent of web standards,
that it's asynchronous,
that it's synchronous,
that the synchronicity doesn't matter.... “
http://martinfowler.com/bliki/ServiceOrientedAmbiguity.html
Three doors marked SOA
Why SOA?
• Business strategy:
– Focus on service delivery (agile?)
• Technical strategy:
– Focus on integration: New applications quickly, reuse old
applications
– and orchestration: Modelling the business (”even a business person
can do it!”)
• Market strategy
– Everything that’s good -> everything we sell (this is the SOA trap)
– Consulting services (”non-technical architects”)
– ”Gartner architecture”
The SOA stack
Validate file
Orchestration
[failed]
[no credit]
Wait for due
date
Check credit
Process
payment
Access Layer
Described
Exposed
Source system
Send message
to user
The vendor stack (marchitecture)
BPEL, BPMN
JBI
WSDL
SOAP
A service in the SOA world seems to contain the usual layer
upon layer of gunk. At the lowest level we have our meat, the
bit that actually does Stuff. This can be EJB or whatnot. Next
up we have BPEL (I dozed off briefly so I really don't
remember how the two tie together), then above that we have
that old dead horse, web services.
- The BileBlog
Source system
Claimed SOA(t) advantages
• Integration
• Orchestration
• Reuse
• I am not going to talk about
– Synchronous/asynchronous
– The horrors of XSLT
– Enterprise service bus (on queue to rule them all…)
Integration: Web Service
• Alias “<CORBA>”
• Promised benefits:
– Integration between various platforms
• Problems
– Service qualities: Reliability, Security, Asynchrony, Transaction
– Platform independence is a truth with modifications
– Competing standards (few implementations)
• Dangers
– Performance
– Synchronous web services
– Limited applicability
”The worst possible way of implementing SOA, is using web services”
- Kaare Nilsen, SOA expert, ObjectWare
Orchestration: Example
Validate file
[failed]
Send message
to user
[no credit]
Wait for due
date
Check credit
Process
payment
Orchestration (and a little ESB)
• Promised benefits:
– Visual modeling of workflow
• Problems:
– Most applications not applicable for workflow!
– Visual != Simple
– Most architects can’t design asynchronously
• The two golden truths about diagramming:
Communicative diagrams can’t be used to generate code.
Diagrams generated from code are mostly useless.
BPEL will fail for the same reasons as CASE
”The only problem with buses is that they never come along when you want them,
and when they do 2 come at the same time.” Posted by Anonymous on the
BileBlog
Reuse: Web services wrappers
• Design for reuse by the world is wasteful
• Reuse by remote interfaces is inferior
• Exposing services that were not designed for it is
extremely risky:
– Security (e.g. SQL injection)
– Scalability (e.g. connection pooling)
– Robustness (e.g. correct error handling)
• Your code has hundreds of these defects!
Designing with SOA…
• Hard to design correctly
• Many existing services are “in-line” DAOs
• Designing for asynchrony is hard (data-access,
workflow)
• Building coarse-grained is hard
Final fallacy: Firewalls
<WEB
• Why do we have firewalls?
• Are SOA applications secure?
• So… do we need “SOA firewalls”?
SERVICES>
Conclusion
• SOA has a fairly substantial cost
• Don’t use it if you don’t need it!
• You probably don’t need it
• When do you need it?
– If you are Amazon, ebay, or google
– If your customers are paying you for it
BBS architecture
Slides not to be published
BBS architecture
• Background: Replacing mainframe batch applications
written in COBOL with Java
• Requirements
–
–
–
–
–
Robustness
Security
Scability (roughly quantified)
Operatability (quanitified)
Maintainability (quantified)
At a glance
online
billing
View
access control
WebController
ServiceRepository
Persistence
external domain repository
entityRepository
domain model
repository
Database
Processing chain
Mottak
Response
access control
Triggered
action
Processing
Processing
receipt
billing
Request
Distribution
other
dependency
Some nice tidbits
• Web layer
– Co-located with business layer
– Standardized dialogs and (MVC) controllers (based on RoR)
• Batch layer
– Message oriented (scalable, robust, flexible)
– Transparent
• Heavy focus on domain layer
Workflow design
• All exchanges RobustInOnly
• All exchanges deliver a Domain Object
• External integration is segregated in adapter classes
– Primary files – everything we get in is from files
• Result: All service call is done through simple java
object calls
Transparent claim check
Response
Processing
queue
Response
queue
Processing
Database
Database
Dependency injection
• Realizes SOA vision of loose coupling
• Interfaces are loosely coupled
– More dynamic interfaces can be an anti-pattern
• Endpoints are specified by Spring configuration
– Implies ”static” routing – but this is seldom a problem!
– Dynamic routing is dumb in many instances
Dependency Injection
Incoming File
Channel
Filedestination
Icky file management stuff
(ick! Ick!)
File destination
File Adapter
(infrastructure)
File destination
Claim check queue
Service
Framework
Adapter
Application
service
File
Database
Report service
Adapter
Integration queue
Print and
distribution
Outgoing file
adapter
Icky file
protocols
External
subsystem
Aspect Oriented Services
• What can be realized as services
• What is missing from Web Services today
– Transactions
– Reliability
– Security
• The field of AOP is largely unexplored
– Billing…
Aspects
queue
queue
Processing
Database
Database
•
•
•
•
•
•
Progress tracking
Exception management
Billing (experimental)
Statistics
Debugging
Exception collation (future)
How do we get the SOA benefits?
• Integration
– Standardized protocols (Bankens Standardiseringskontor,
cirka 1990…)
• Orchestration
– Remove temporal coupling
– Simple, static workflow
– Driven by single, simple events
• Reuse
– Code and design reuse (patterns)
– Primarily in-process (rocket science: method invocations…)
The SOA doors
SOA is everything
that is good
SOA is everything
we sell
SOA is integration
Conclusion
• Your most pressing architectural risks are not solved by SOA
• SOA’s vision is not new
• The SOA stack may not be your best bet
• The vision can be archived by old technology with a new twist
for real benefits
• Build simple, robust, and for today!
• SOA might not be wrong for you, but I recommend ignoring it
until you know you need it.