I was introduced to Scala by a colleague around 4 years ago via the Lift framework. At the time I dismissed the language, preferring to focus my energies on Ruby and Ruby on Rails. 4 years later and Scala is getting some serious water-cooler time - especially since the Ruby vs Scala flame wars prompted by Twitters move from Ruby to Scala for back-end grunt. So I choose Programming Scala - Tackle Multicore Complexity one the Java Virtual Machine as the book to guide me learning the language as a relative noobie. This blog is a brief review; Pro’s and Con’s followed by a brief summary.

Pro’s

• Writing style: The author keeps the language simple and the content flows nicely. My cover-to-cover read time was a near record.

Con’s

• Unusual chapter order: Introduce exception handling constructs after explaining concurrent programming and test frameworks? Exclude XML pattern matching from the pattern matching chapter? Explain reverse function calls in the midst of explaining collections? Some very strange decisions were made about the books structure.
• Repeated explanations: The last few chapters briefly describe syntax covered in depth earlier. This gives the impression the author brain-dumped latter chapters without thought of earlier chapters.
• Depth of content: It falls short explaining how the Scala library implements some of the language features. As it targets the experienced Java developer, the audience will find it falls short explaining how the features are realized through Java. The library apparently has some great examples of how to use the language effectively - yet these are never explained. It would also be great to appreciate why the language authors preferred syntax cryptic to the untrained eye like this:
  
for(node @ {_*} <- nodes) { ... }

  or this:
  
val total: Int = (Map[String, Int]() /: (rootNode \ “element”)) { (map, element) => … }


• Idiomatic use not mentioned: No mention is made of idiomatic use of the language other than encouraging use of a few methods accepting closures. I expect more from a language guide.
• Code examples poorly factored: Too often code examples in language guides stink. This is no exception. Don’t explain to me the value of refactoring and TDD and then proceed to present poorly structured code. Authors should encourage good form in their readers by consistently presenting good form themselves - no excuses. Show me you are an expert in what you do.
• ‘Tackling Multicore Complexity’?: There is only one chapter on concurrency. It only goes so far as to explain the language constructs without going into details on patterns of their use. The hardest consideration of concurrency is how to test it - but there’s no mention of approaches for that. This makes the title of the book misleading. The main sales pitch falls short.

Summary

It’s not a detailed language guide. It doesn’t cover functional programming in depth. It only touches on concurrency. I am now confident I understand Scala’s syntax, however, I’d be short on the confidence to apply it solving real world problems without an understanding of similar languages. Overall 5/10.

As the community continues to invest in Web Services, particularly through the rise of SOA, vendors are adding to them an obscene amount of capabilities via specifications collectively known as WS-*. When I last looked there were no less than 48 in the set. 48. That has to be written again – 48. Obscene. Given no one body regulates the set and vendors are after a piece of the SOA pie, you can see how this has all come about.

It used to be so simple – just code invocation via the web. So I write this post as I recently had a wonder through these specifications to see if anything was actually of some use.
Turns out there are a couple.

• WS-Security for message signing and encryption. It can be useful if HTTPS communications is not for you. Turns out that its performance can be dismal though.
• WS-ReliableMessaging for messages that simply must by received.

Out of 48, for mind, these 2 are clearly the most useful. Admittedly others have benefits in certain situations – but note that a large majority of the 48 are proprietary and some far from realization.

Another I imagined could be useful is WS-BPEL, a standard describing a language that allows one to orchestrate (apparently not be confused with choreograph) a Web Service facade that invokes other Web Services and applies transformations to data. Apparently this language is easily visualizable, allowing non-developers to orchestrate the interactions. However, when I saw the section of this Open ESB presentation dedicated to WS-BPEL I laughed. Code is surely easier to understand than some of the visualized examples therein. There is a crescendo as well – check out the claims of ‘Near 0 coding’. Why oh why? Code is not the enemy – clearly some of these sorts of tools are. Developers prefer not to use them and, given the concepts at play, those in business facing roles never will either.

Fowler famously gave up on SOA encouraging the community to find other terms to describe its various constituents. Instead, the term has only become more prominent and synonymous with more concepts and technologies fed by the big vendors and their vast array of product speak. They employed the services of OASIS in an effort to save the term and succeeded – shoving all those concepts into a broad reference architecture.

Nevertheless, with the term continuing to gain traction and a wealth of related technologies surfacing, I recently ventured into the ivory-towers of SOA trying to grasp some worthwhile truth from the reams vendor-speak out there – with terms such as ‘adapt dynamically’ and ‘business agility’ exclaimed in many a paragraph.

This blog documents my initial experiences wading through the reference architecture and related explanations of SOA. My intention is briefly summarize SOA, condense important terms used in the architecture and offers reasons why the architecture can be of some value.

What is SOA?

SOA is high-level architecture, one that can be realized through a multitude of concrete, low-level, architectures. Its focus is on services and interacting with them. Services have been in existence for decades – companies have extracted important shared behavior into some re-used API for a long time. Technologies have been around equally as long allowing these API’s to be invoked both locally and remotely. The architecture simply encourages you to think about things slightly differently so code shared within an organisation and across organisations can change faster. More concretely, it encourages you to keep these things in mind:

• Define worthwhile services. Their behavior should be useful and serve multiple consumers.
• Rip services out of your apps. Services have traditionally been embedded within apps. Treat them as separate entities, and version and deploy them as such.
• Be vendor independent and support heterogeneous computing. Support consumers using different message delivery mechanisms and technologies.

That’s the guts of it. Physically separating services and treating them independently rather than conceptually separating them and embedding the within applications is, for mind, the key message. Services can then change independently of the applications using them and, among other benefits, multiple versions can be deployed to serve different needs.

SOA Terminology

I’ve divided the terms into two sections, the first more abstract terms, and the second terms more concrete that verge on implementation terms.

Abstract Architectural Terms

Service

An entity performing capabilities (aka processes and behaviors) meeting the needs of consumers.

Realization: Some behavior exposed via an API.

Service Description

Describes the capability of a service and how to use the service. The description seeks to aid both human understanding and automated interaction. It is composed of an Interface, Policies and Contracts.

Realization: API contracts such as WSDL, in code assertions, post-process reconciliation.

Service Interface

Details of protocols, actions and information exchange performed.

Policy

Describes how to interact with a service considering such things as security and SLA’s (e.g. around frequency of use). Automated and manual enforcement is possible, as well as enforcement prior, during of after interaction. Akin to assertions by a Service on it’s expected behavior.

Contract

An agreement between consumer and provider to behave in a specific fashion. Akin to assertions between 2 or more parties, as opposed to Policies which are assertions by 1 party.

Service Provider

Provides a service for use. Multiple perspectives are possible, e.g. the organization/person providing the service or the technology exposing the service.

Realization: An organization such as Amazon, technology such as Apache CXF.

Service Consumer

Uses a service. Like providers, multiple perspectives are possible.

Realization: An organization such as The NY Times, code binding to and invoking a service.

Service Participant

A term describing either a Service Provider or Service Consumer – a generalization.

Visibility

A service and consumer must be able to connection and comply with description for information exchange. Noteworthy as a service can be made visible via a directory or registry.

Realization: Use of UDDI for service discovery via a directory.

Interaction

An interaction between service and consumer. A conceptualization of communication between the two. Consists of an information exchange via described behaviors.

Realization: Point-to-Point communications via HTTP and TCP/IP, an event triggering a service via timer or a change in state, message transmission via MOM.

Execution Context

Embodies an interaction from connection through to completion. Each interaction has a dedicated context which incorporates the connection between participants, the interpretation of information exchanged, enforcement of assertions and execution of the service.

Effect

The consequence of interacting with a service. Usually a state change and/or retrieval of some information.

More Concrete Terms

Message

Embodiment of a request to or a response from a service.

Message Delivery Mechanisms

Message delivery can be both synchronous and asynchronous. Services can be exposed via Web Services (WS-* or REST), simple XML data exchange over HTTP, MOM such as JMS, SMTP, CORBA, COM/DCOM, direct API invocation…

Point of emphasis here is that SOA is not realized solely through Web Services and WS-*.

End-Point

A discoverable location from which a service can be accessed.

Realisation: Connection details such as a URL.

Interaction Patterns

Examples of patterns consumers can use to interact with a service:

• Simple Request-Response: Direct invocation of service from consumer.
• Discovery: Appropriate service is discovered from directory.
• Probe and Match: Query a number of consumers, discovering which consumer fulfils some criteria leading to a subsequent invocation.
• Subscribe and Push: Consumers subscribe to services and receive callbacks for significant events.

Is SOA valuable?

So SOA is not rocket science and the concepts embodied in the terms mentioned are nothing new. For an organization with services embedded in applications that lack a well-defined API, it’s going to be expensive to adopt. On the other hand for an organization with those API’s well-defined and tested it will be much easier. For another organization they may have only one application and no behavior exposed externally, so who cares? The key questions for an organization to consider are:

• Do I expose behavior for external consumption?
• Is it hard for me to change applications where I have ’services’ embedded?
• Am I finding it hard for a service to fulfil the needs of multiple consumers?

Again, for a healthy codebase that’s well designed and tested, if you need to move in an SOA direction your task is significantly easier. If your not in this situation, then I suggest that should be your first step and where you spend the bulk of your investment.

References

What is SOA anyway?

Geospatial Service Orientated Architecture

Service Oriented Architecture (SOA) and Specialized Messaging Patterns

Smart SOA: Best practices for agile innovation and optimization

Update: Uncle Bob agrees with my conclusion in his blog entry A Rational Plan to Start using SOA