John Crupi, Michael Hulton, and Michael Wright, all from Sun Microsystems
Integration difficulties, accidental architecture. Inflexibility of IT infrastructure, complexity of integration projects, integration costs, time to market, limited partnering flexibility, limitations of EDI.
SOA moves from monolithic, closed apps to shared network-based layered services. Low -> high: Resource layer, service layer, process layer, access layer.
The "move" to SOA is a process of moving from "spaghetti" to "lasagna".
SOA definition: An integration architectural style for XML document-based, exchanges using shared, loosely-coupled, network based software services. Open standards based SOA architectures tend to be best realized using web services as the middleware technology.
To really acheive the ability to share, you have to have better separation in the architecture.
SOA is a combined effort between IT and the business units. IT acts as the service layer provider, business operates as process layer definer. This is forcing IT to think more about what the business wants.
Bad practice: don't take everything you have and wrap it as a web service. It must be top-down, business-driven. If you don't understand the business requirements, you shouldn't be doing SOA.
SOA Architectural Rules
Design focused: Coarse-grained business services - defined in terms of what the business thinks of as a service. Document based. Mostly asynchronous - easy to understand, hard to implement. Conversational - think about the information exchange that's happening.
Reliable, secure/identity, policy driven, registered and retrieved.
Standards focused: WSDL described, BPEL orchestrated, JBI-based.
Java Business Integration (JBI)
JBI is a standard "meta-container" for services. Standard SPI for plugging in engines to provide and aggregate services, and bindings to provide protocols and transports. Composite, event-driven services. Extensible administration, loose coupling via WSDL message exchanges.
JBI container has binding components (e.g., SOAP, FTP, REST, ebMS), send them through a message router as normalized messages to service engines like BPEL, Routing, transformation, correlation. Normalization means that any engine can understand the headers on any message. Normalization != canonicalization.
JBI service engine hosts the business logic that implements services. Exposes service endpoints agnostic of protocol and transport. Engages in message exchange patterns. Is a target for deployment - a container.
Binding components handle protocol-specific message reformatting. Deals with wire transport of messages (e.g., SOAP/HTTP, FTP, SMTP, JMS, ebMS, AS2, etc.) Should contain no business logic. Exposes proxy endpoints for remote services. Proxies JBI services to remote consumers. Reused by multiple service engines.
JBI administration: standard installation of components with portable archive format. Services Assembly (SA) & Service Units (SU), Lifecycle management (start/stop/shutdown).
Enterprise Service Bus (ESB). JBI is a single-instance spec - what if you need horizontal scaling? ESB is highly distributed scalable services. Based on MOM XML passing.
A practical SOA scenario. Problem: corporate silos, islands of automation. Redundant, not integrated.
Introduce process layer to move coupling out of services layer. BPMN diagram of scenario leads to BPEL process artifacts.
- Find / create integration artifacts
- Package Service Units (SUs)
- Assemble into Service Assemblies (SAs)
Summary: SOA is a layered approach. Integrated and shared services and processes. Standards-based: BPEL, JBI, WSDL...
JBI and JBI-based ESB standardizes pluggable integration components, administration of composite services, message exchanges. Provides loosely coupled SOA "meta-container".