By Frank Nimphius-Oracle on Feb 20, 2013
Just finished reading "SOA Made Simple" by Lonneke Dikmans and Ronald van Luttikhuizen, published in 12/2012 by Packt Publishing and use this summary to share my thoughts.
"SOA Made Simple" is a very good book that - beside of helping readers to do SOA right - will have an impact to how you look at going out for breakfast. The "breakfast example" is one of the great samples that the authors consistently use throughout the book.In addition, this book is well written and covers really no fluff but just stuff. Reading this book you learn what SOA is, the benefit it brings to IT, as well as how you design and model your SOA and services.
Whenever Packt asks me to review and write about a new book, I ask for a printed copy so I can annotate the page with comments and questions. My copy of this 257 page book has a lot of annotations, mostly about information I want to share in my review.Too many annotations, which clearly indicates I liked the book, though I am not directly involved in SOA (which probably makes me the perfect candidate for reading this book). According to the Preface, yes I read this too, the book is "for anyone (architect, designer, developer, administrator, team lead) who is implementing or is about to implement SOA in anIT-related environmenet". Well, I would call this mission accomplished and recommend you to buy this book for your learning and career.
So lets have a look what this book covers and what I liked so much:
Chapter 1: Understanding the Problem
This chapter is a well structured introduction to the current state of IT that leads to a problem statement that demands for SOA to come for the rescue. However, though A SOA book, the authors don't make it too obvious that SOA is the answer. The chapter also gives you some questions by hand you should ask before starting a SOA project so you ensure your decision is right before starting a SOA project. This chapter also introduces the examples (I already mentioned the diner for breakfast, but there also is an insurance business and others).
Chapter 2: The Solution
This chapter introduces services and the SOA term. It does so not from a pure technical perspective and without calling WS* services too soon. Or would you have considered the waiter service in a diner to be a service? In fact it is and therefore services don't need to be SOAP or REST to be called a service. SOAP and REST come into play later, when the talk is about standards and SOA.
Chapter 3: Service Identification and Design
This chapter introduces various concepts around the design of services like top-down, bottom-up and meet-in-the-middle. Walking towards WS services, this chapter summarizes and explains service characteristics. Unless you are a WS expert already, this is one of the chapters that really help you to understand what a service should be, how isolated and de-coupled it must/can be and how complex IT architectures can be mapped to a sensible service oriented architecture.Here you get a good analogy of services to lasagna (really good examples that stick as pictures)
Ps.: As a note to the publisher, I think the images on page 73 and 74 are in the wrong order. Too late though, the ink has dried.
Chapter 4: Classification of Services
This chapter allows you to organize services into elementary services, composite services and process services. It also covers the difference between service composition (BPM/BPEL) and aggregation (ESB, client). Other concepts for organizing services in this book are: granularity, actor (who works with a service), channel of access, security requirements and many more.
Chapter 5: The SOA Platform
This chapter switches gear for a moment and uses SOA terminology that hasn't been introduced until here but is getting explained in the following. The chapter also talks about REST and SOAP services as first class citizen technologies in a SOA. This chapter thus is where you learn about ESB, BPM, Case Management, Events, Business rules and user interfaces to SOA (which is also where Oracle ADF gets its mentioning). A lot of pages are dedicated to service security, design and develpment tools.
Chapter 6: Solution Architectures
Chapter 6 is one of my favorites and compares SOA offerings and suites provided by Oracle, IBM and Microsoft, allowing readers to understand what each of these vendors has to offer and how products could integrate. The chapter doesn't announce a winner, which I think would be a bad move for a generic SOA book, but really saves you from investigating this yourself. As the authors stress it, it is important to understand what is best in breed for a project and where you shop this best looking at the full package.
Chapter 7: Creating a Roadmap, How to Spend Your Money and When
This chapter discusses what it takes to implement SOA in a company: stake holders, requirements, wrong and right expectations, benefits and money gains. Personally I think the graph on page 1999 is a great idea for showing what you can expect on each of the stages involved when implementing SOA. Its really well done.
Chapter 8: Life Cycle Management
What you build today is what you maintain tomorrow and throw away the day after tomorrow. This basically is what the authors call the the lifecycle of SOA solutions. and in fact its all about change management and the conflict that exists between developer and administration personnel that both have a different agenda. Governance plays into this as well. Basically you learn that you need to keep the "eye on the bal" during the realization of SOA architectures.
Chapter 9: Pick your Battles
This chapter is all about how to get people to buy in to a SOA architecture and how to ensure that the implementation - especially when implemented in distributed teams and by different departments - follows defined rules and definitions without being prohibitive to change.
Chapter 10: Methodologies and SOA
This chapter discusses the impact SOA has to different aspects of software development and provides methodologies to use.
In case you did not order the book while reading my review, here's a dense list for why you should:
- Clear story line
- Chapters that make sense and float
- No fluff just stuff
- Explaining complex concepts simple in real life examples
- Back / Forward references
- External document references
- Good SOA coverage from a project perspective looking at SOA as a whole and not just services
The one thing I wanted to have immediately when reading this book was a second book that closely follows this book's chapters and that - by example - shows how to implement various SOA components for people to have example code and instructions. This could be using the Oracle stack (preferred) but also would be valuable for any of the other introduced vendors. However, code and implementation samples was not in focus for this book and this is good the way it is.