I attended the session “Service-Oriented Architecture and Java Technology” by Steve Jones, Head of SOA Global OS, Capgemeni, and Duane Nickull, Senior Technology Evangelist, Adobe.

This session explained SOA, and how it works with Java. SOA was defined as an architectural paradigm for organizing and using distributed capabilities that may be under the control of different ownership domains. It is a framework for matching needs and capabilities, and a view of architecture focusing on services as a mechanism to allow interactions between those needs and capabilities. It’s also a way of thinking about problems.

The OASIS reference model for SOA has been the industry standard since 2006. It’s not an architecture, but an ABSTRACT model for a range of service oriented architectures and analysis comparison. OASIS is A framework for understanding relationships among the entities.

Here is the core model for SOA. It consists of a service in the middle surrounded by visibility, a service description, interaction, contracts and policies, real world effect, and execution context. The example of Starbucks was used to explain each of these model components. The service is “buy coffee”. Visibility is the Starbucks green and white sign. The service description is the Starbucks menu of different coffees. The interaction is the order that is placed for coffee. The contracts and policies would be the requirement that money must be given to receive the coffee order. The real-world effect is that the coffee is received and taken out of the store, and the execution context is that in the United States the coffee must be purchased with US dollars. However in Great Britain, British pounds must be used.

When creating a SOA implementation, technical infrasture is secondary to the reference architecture. The architecture must confer effectiveness, confidence and scalability. “If you don’t start with services, you’re not doing SOA! ” There is no Web 2.0 without SOA. Pretty interfaces are nothing without the trust of a reliable service.

SOA is thinking about systems. In order to effectively do SOA, one must think in terms of services by organizing the teams around services, and consider processes and mash-ups before even beginning to look at the user interface. Think about measurements for the service such as the business SLA’s, and finally, think about standarization by asking the following questions:

• How are the interfaces defined?
• How are they versioned?
• How are they tested and verfied?
• How are the dependencies managed?
• What is the right technology for the service?