Tuesday, June 28, 2005

JavaOne: Pragmatic SOA, a case study

Notes from JavaOne 2005...

Experiences of RouteOne web services implementation.

Critical problems they had to solve: Single sign-on. Accessing volatile dealer information at runtime. Import credit application. Orchestration.

Single sign-on using SAML and XML-DSig, an OASIS standard XML framework to exchange User Credentials. Basis for Liberty Alliance Project, supported by many vendors and products.

B2B messaging using WSDL binding. Document and binary exchange strategies. Aysnch and synchronous messaging. WSDL supports more bindings, but they only use RPC literals and document literals.

Strategies for document exchange:
  1. Represent the document as a string. Highly interoperable, fleible. Can start with Java technology interface first and generate WSDL. Document serialized to the wire with tags escaped. Need out-of-band agreement on the schemas.
  2. Specify the schema in WSDL. Self-describing. validation and binding done in the pluming.
Strategies for binaries:
  1. SOAP with Attachments (SWa). Generally accepted, multipart MIME with SOAP.
  2. Embed the attachment in the SOAP body or another part of the message or as base64 binary. Simple, but large strings might choke some parsers.
Security - XML Signature (XML-DSig) provides authenticity, integrity, and non-repudiation.

Reliable Message Exchanges - goals: guaranteed delivery, duplicate elimination, delivery in sequence. Competing standards: WS-Reliability, WS-Reliable Messaging. Use conversation ID to identify conversations, along with message sequence numbers. "At least once" delivery - messages are retried until TTL expires. Messages are re-queued in case of failure at any stage. Duplicate elimination by sequence number. Replies include reference to sequence number being replied to.

Orchestration standardized on WSBPEL. Executable process, declarative approach. Transparency for business owners. Build on WS stack. Implementations available today. Accepted by most EAI vendors. Like a programming language.

WSBPEL primitives: Roles, synchronous services, asynchronous services with callback, routing, faults, in sequence and parallel, in a loop, branch, assignment, dehydration and rehydration of state, correlating messages.

How BPEL improves things: Proper layering. Black box. State of conversation is automatically tracked. Seamless integration between process and services used. Integrate with POJOs, EJB, DataSource.

Traditional EAI tools: no standard conceptual basis. No common services expectation. Partial implementation of standards. Extension issues. Vendor lock-in.

JBI should do for integration what JMS did for messaging. A standards-based integration solution with pluggable components, normalized "canonical" message, normalized message router service, lifecycle and management through JMX, ESB could be a realization.

How JBI impacts: Proper layering. Loose coupling between Process and Service layers. Leverage BPEL engine for orchestration. Leverage SOAP and JMS tech binding components for transferring data to external systems. Vendor-neutral stack.

Note that they did all this in 2003, so it should all be reasonably doable today.

SOA layers: Access Layer / Process Layer / Service Layer / Resource Layer.

SOA big rules at RouteOne: Coarse grained, document based, mostly asynchronous, conversational, reliable, secured, WSDL described, orchestrated.

Pragmatic SOA: Start simple. Let the business identify the service. Think XML documents not objects. Use SOAP as an envelope but not for binding. Use WSDL for description not code generation. Think asynchronous conversations. Use WSBPEL to orchestrate the process. Use JBI for integration.

In summary: Let business describe the service. Use SOA big rules appropriately. JBI provides loose coupling and vendor independence. Be pragmatic - start small and realize the benefit. Keep learning, this is just starting.

No comments: