JavaOne. Service Oriented Architecture and Java Technology: Level-Setting Standards, Achitecture and Code.

A session by Steve Jones and Duane Nickul

Exploring the OASIS reference model, so that we can have a reference point for understanding and articulating SOA.
It’s very tough when you ask questions like:

- how does SOA differ from other types of architecture?
- If SOA is x, what is the antipattern?
- How does Java relate to SOA?

We need a common point of origin to let us have a sensible discussion about SOA because we all say it is different things, and this is not aided by the product vendors.

So, what is the RM?
- An ABSTRACT model for comparison and analysis of a range of Service Oriented architectures
- A framework for understanding relationships among the entities in a SOA environment.
- Industry standard (OASIS standard-2006)

RM is obviously a reference model, but also by not tying itself to existing technologies it is durable.

The elements are a Service, Visibility, Service Description, Interaction, Contract and Policy, Real world effect and an Execution Context.
The RM is guided by patterns, reference architecture, related models and concrete architectures. It considers protocols, profiles, specifications and standards.

Service: A mechanism that brings together needs and capabilities.
Service Description: declaration of aspects required to interact with the service.
Capability: a specific set of functions resulting in a real world effect.
Visibility: How those with needs and capability see each other and interact.
Execution Context: technical/business elements that allow information to be exchanged, actions to be performed and enforce policies and contracts
Policy: constraints imposed upon invocation.
Real World Effect: The result of an interaction with a service.
Interaction: the models for using the service.

So, the RM covers all the things you need to successfully produce and consume a service.  It also helps describe the critical success factors e.g. manageability, trust, predictability, real world effect, governance, that allow us to communicate successfully.

It’s 2008 it must be the year of Complex Event Processing because BPEL is SO last year

SOA and Java – Differences
J2EE has a single domain of ownership – SOA has many
Java has reliable semantics (some)
SOA is more about the interfaces and the effects than the implementation
SOA needs more thought and design to establish those formalisms

SOA and Java – Similarities
A Service and a Java API are notionally similar.
Encapsulation, Service Transparency/Autonomy are similar
SCA and SDO are good SOA implementation approaches

Some good tips on getting SOA done in Java:

• Think in terms of services, and organise your teams around them
• Think of process and the UI second
• Think about measurements for the service – business SLA
• Think about standardisation. How are interfaces defined, versioned, verified and how are dependencies managed?
• Pick the appropriate technologies and standards – e.g. JAX-WS, SCA/SDO, Apache, IBM etc.
• Maintain consistency in the model – remember that that is what the RM brings to Java
• Remember chang is likely insulate yourself with proxies
• REST can also be compatible with the OASIS RM.  If you know Steve, you know he LOVES REST

Then there was a good live demo, pulling latest builds of vendors RM’s and making it work, taking WSDL into Flex, which uses Apache Axis 2 to generate stuff.
This all works because of a reference model and because standards are a point of reference for vendor implementation.