Service Oriented Architecture With Java 110
Martijn de Boer writes "The book has been written to provide the reader with a short introduction to the concepts of Service Oriented Architecture with Java. The book covers the theory and analysis from the start and is progressing to a more intermediate level slowly throughout the different chapters. This book has been written for software architects and programmers of the Java language who have an interest in building software using SOA concepts in their applications. The cover hints to a series called “From Technologies to Solutions”, and that is exactly what this book tries to do, it tries to explain the SOA technology with different case studies and a path for solutions for your applications." Read below for the rest of Martijn's review.
When I ordered the copy of the book, I was under the impression that I was required some familiarity with terms used in the world of SOA but I was rather fond of the easy explanation of terms in the first chapter. The first chapter starts off with a small introduction to the role of software architecture when thinking about a software project. The chapter covers alternatives to SOA and tries to get the reader onto the right path for the rest of the book.Service Oriented Architecture with Java | |
author | Binildas A. Christudas, Malhar Barai, Vincenzo Caselli |
pages | 192 pages |
publisher | Packt Publishing |
rating | 8/10 |
reviewer | Martijn de Boer |
ISBN | 1847193218 |
summary | This book is an overview of how to implement SOA using Java with the help of real-world examples. It briefly introduces the theory behind SOA and all the case studies are described from scratch. |
Later on in the book different subjects pass, the first few chapters start off with the basics of using XML as a communication layer. The third chapter introduces the audience to different implementations of web services in the Java world including the most familiar names as Apache Axis, Spring and XFire. The reader will be shown and guided to the install process of these web services and is being shown around the process of working with the software. The pros and cons of every piece of software are shown when following the steps throughout the chapters.
The book ends with chapters providing case studies of real world examples of SOA and alternatives. I have found this to be the most informative section of the book when looking to make decisions on how to architect a software project as it provides several examples on when to use which aspect of SOA. The different case studies allow you to put some weight and foundations into your decisions. The last chapter of the book is basically a conclusion of what we have learned throughout the book and provides a clear summary of goals of using service oriented architecture.
The reader is expected to have understanding of Java to follow the examples throughout the book. Examples are demonstrated on Windows machines, but could be followed on any other platform as well without having the hassle of setting up a different environment. That is one of the advantages of Service Oriented Architecture with Java, because it basically can be ran everywhere.
When you work your way throughout the book, you will discover different clearly illustrated diagrams and other informational graphics. There are more than enough images to make this something other than a boring theory book, as the images often provide a better understanding of different explanations of architecture and setups.
The book covers a small setup with Apache Axis 1.3 and mentions to use this opposed to the more recent 2.0 version because more software is being implemented on top of the 1.x series of said web service. However because the reader is starting to learn about SOA, it would have been great to see some of the differences and read why 2.0 hasn't been adopted much yet. I would have liked to see a bigger comparison between those two versions, but as the authors point out, there is a great community for both versions which provides a lot more background information if you want to look further into the more technical information that isn't provided in the book yet.
This book is a good way to get your feet wet in using web services to build and architect powerful Java applications for your business. I am no big Java developer yet, and I needed this book to navigate through the different pieces of software available, it succeeded very well at that point. I was fond of the clear writing style, which has always been the case by books from Packt Publishing. The book also has been written in a logical order, putting case studies at the end of the book so they are better to follow. Most technical books I own are written in a way that allows you to jump from chapter to chapter in an order that you need them, but I found this book to be a solid line of information of which the difficulty grade builds up from beginning to end. As a developer and software architect I really appreciate how well this book has been written for this audience, it's almost as if it was written especially for me and the knowledge I had of service oriented architecture.
You can purchase Service Oriented Architecture with Java from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Re:I'll admit... (Score:1, Insightful)
I hope you are not from the UK. If you are then you would be guilty of an offense under the computer Misuse Act. What you are doing is intentionally putting malware(ie changing the operation) onto computer without the knowledge or permission of the user. If you did this in my company it would be groun for instant dismissal. The person using the USB stick could be in deep shit as well.
Humour bypass intentional.
Re:I'll admit... (Score:3, Insightful)
SOA is great but... (Score:4, Insightful)
Re:I'll admit... (Score:3, Insightful)
Re:Save Our Asteroids (Score:5, Insightful)
Anything that uses XML for RPC and has no concept of distributed transactions (Compensation) rightfully deserves to continue its steady march into irrelevent obscurity
SOA does not mean you have to use Web Services or XML over RPC to implement your services. A service is defined (by most people) as a piece of Software that follows some principles, like ... ... but you could use simple jars, dlls or hell... stored procedures if you want.
- be interoperable
- having a defined interface
- be reusable
-
Web Services just happen to be used because they are interoperable, define an interface,
And, btw, Web Services have a standard for distributed transactions [wikipedia.org].
As for SOA being irrelevant I dont't agree: the theory behind it is nothing really new. It just tries to define some common sense and document one of the many ways you can architect the software you write. It may not be the solution for everything, but for some business cases it's the right tool.
Teaching SOA using a single language? (Score:3, Insightful)
Isn't the purpose of SOA to be platform and language independent?
I would think that a book on SOA that covers a single programming language is missing a key aspect of SOA.
I understand that if someone is writing an SOA application then the application can be written in Java only but I would expect the application to be tested using several languages.
Re:Save Our Asteroids (Score:2, Insightful)
That's like saying "OO Design" is a load of marketing bullshit. All SOA does is formulate the principles of "service-orientation" (as OO Design formulates principles of object-orientation). SOA is unique in that there are truly standard and interoperable implementations (WS-*) that support service-orientation.
In a sentence, SOA is the natural, evolutionary extension of object-oriented (and even aspect-oriented) design to the network, using open and widely-accepted XML standards as the distributed programming language.
Re:Java is a great *idea* (Score:5, Insightful)
Unfortunately the implementation is poor.
Can you name a faster and more reliable implementation? Didn't think so.
Java held out the promise of write it once run it anywhere, but that promise has yet to be fulfilled as there are still differences from platform to platform that make developing in it a chore rather then enjoyable work.
If you use pure java code the cross platform stuff just works. Period.
Most of the problems are with the various implementations of both JIT's and VM's and mostly having to do with how things are abstracted eg: big -v- little endian, file access and those sorts of things.
What does this nonsensical gibberish mean?
The tons of lib's that are mentioned as a god send have their own problems as well but that has more to do with programmer quality then anything else, but even the well designed and written ones still overlook the JIT and VM problems and then you end up having damn quirky behavior that can take weeks to track down, hence the problem of everyone sending out a complete JRE with their program and you end up in JRE hell with 14 different versions of JRE's on your system.
If you target older jre's you'll get very good compatibility across the board. There used to be issues caused by Microsoft's JRE... but that's why they built it. If you target a bleeding edge ANYTHING, you're going to have compatibility problems.
I liked the IDEA of having SUN control Java because at least things would have been consistent but that failed as well with to damn many versions being released. Now we have everyone and their grandmother writing JVM's JIT's and JRE's and none of them do anything exactly the same which has thrown ever more variability into the mix and just made everything messier since suddenly you now had to install vendor X's JRE or VM because some fool decided that it made everything 1% faster and they JUST had to have it or alternatively it had a COOL name.
Why do you keep randomly throwing the acronym "JIT" everywhere? Again, you just poorly restated your earlier comment which isn't true and makes little sense.
I see the biggest problem with WEB development today as two things. 1. Lack of a statefull connection and 2. The proliferation of languages with linguistic and syntactual differences but little else to set them apart except a fan club. PHP, Ruby, Python, VB, Perl, all of them doing the same thing, serving the content.
1) ???? How does this affect Java in anyway? 2) ???? How does this affect Java in anyway?
The fundamental paradigm of the web is broken and needs repair badly. The solution is to split it, as I have said before, into two distinct camps, the Application Web and the Text and Pretty Picture Web because trying to mix the two has proven to be a miserable failure.
????? WTF
In summary,
FlyingGuy, what you've just said is one of the most insanely idiotic things I have ever heard. At no point in your rambling, incoherent response were you even close to anything that could be considered a rational thought. Everyone on this site is now dumber for having read to it. I award you no points, and may God have mercy on your soul.
Re:I'll admit... (Score:4, Insightful)
Re:I'll admit... (Score:1, Insightful)
Aside from the familiarity of Java, what benefits would Java offer for web services?
Compared to VB, one huge, huge advantage: Running on a server class operating system.
Re:Teaching SOA using a single language? (Score:3, Insightful)
If you're concerned about interoperability, then you will obviously test with other languages. But if you're building multiple services in your company/business for your use, and you're all using Java, then I don't see any reason to use another language. Although, I'd prefer to use OSGi as then you avoid the whole XML thingy.
Re:Java is a great *idea* (Score:3, Insightful)
Just checked my 401K. Fidelities website requires applets for certain functions. Someone cares about applets.
So, the map of the conversation is now:
-The language works every.
-No it doesn't. Here is a proof of concept that you can try yourself.
-No one cares about that part of the language.
Re:I'll admit... (Score:2, Insightful)
Java is new in the Real Time space, it is true. Real-time, low memory footprint behaviour has never been a goal for core Java. So your comment makes you seem foolish. ("The iPhone is crap because it still won't brew my coffee, unlike this coffee machine over here!!")
If you want to spend your life reinventing the garbage collection wheel, you are welcome. I have been informed that any sizeable c++ app needs some sort of garbage collection algorithm.... I don't have enough c++ experience to factcheck that. If it is true, then I would certainly trust the guys at Sun, Ibm etc to do it better than anyone in any given enterprise.
Java is for people who want to get work done and still have a life at the end of the day. Java is focussed at business applications, but Java can do a lot of things very well nowadays - most of the mud thrown at Java was true a decade ago, but is no longer true at all.
Real time java is on the way, though: http://en.wikipedia.org/wiki/Real_time_Java [wikipedia.org]