Slashdot Mirror
Service Oriented Architecture With Java
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.
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.
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.
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.
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.
assembler is slow and useless, I write all my code in pure machine code.
The only "service" I started from Scratch was the one to make the CD Tray eject every 5 minutes. It's been alot of fun pulling pranks on room mates and co-workers. However my co-worker had the profound idea of putting this on a handful of USB sticks and have it auto-install when plugged in to a computer. Then we toss a handful of these things in the parking lot, and whoever puts in an IT Request about it gets fired.
As for the book, I've never worked on a web service in Anything but VB, it handles everything we need it to do, which is very basic (pun intended).
Aside from the familiarity of Java, what benefits would Java offer for web services?
... and actually write my proposed book: "Software Design With Popular Acronyms"
XML is a known as a key material required to create SMD: Software of Mass Destruction
In Dutch SOA stands for "Sexueel Overdraagbare Aandoening", or Sexually Transmitted Disease. Someone at my office recently received the prestigious title "SOA Expert", which of course has led to very strange looks from the mailman when a package arrives for him.
It's been several months, and the joke still hasn't gotten old, which shows either the level of inappropriateness of the title in Dutch or the maturity of the people making the joke. (I'm guessing the combination of both)
SOA, Java, Axis 1... Did I take a time warp to 2003? Hard to believe that this would be of much interest these days. Also, CXF is a lot better than Axis, and who still uses Axis 1? Come on...
Java is mature. Not really the leading edge anymore. The SOA hype did come and go.
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.
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.
I just don't trust anything that bleeds for five days and doesn't die.
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.
What a bunch of babies everybody is. We implementing method calls in XML over HTTP from server to server as if they're pretending to be frigging browsers to each other. Remember when the world was simpler and we were using CORBA for that stuff? Or when we were going down to the TCP/IP layer and using sockets, and figuring our own stuff out? Before TCP we were sending raw IP packets. Uphill. Both ways. And it was good enough for us. We weren't kids anymore, writing BASIC programs on our little 8 bit machines. Of course BASIC was way too slow and you really had to go down to the machine code level to write anything that wouldn't embarrass you in front of your little friends. Really, all this stuff is based on a protocol that everybody should be using: TTL. And transistor-transistor logic should be good enough for anybody. If you can't rewrite your goofy SOA application using TTL it just shows how ignorant you are about what you're really doing.
My applets run just fine on a Timex Sinclair 1000.
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.
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.
Mod me down, my New Earth Global Warmingist friends!
Like the applet not being able to regain keyboard focus in a browser running on Linux. That is, you click away to another window or something else in the browser, and then you click back on the applet. Unless you click in a text box, your key listener won't respond to input.
Yeah, I found out this one is a couple years old, as I've been trying to get my software to work.
Aah, change is good. -- Rafiki
Yeah, but it ain't easy. -- Simba
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.
Umm...no.
Write an applet with a keyboard listener that will play a sound clip when the spacebar is pressed. Put a button and a text area on there. Make the button play the sound for good measure.
Load the applet in firefox on windows. Hit the spacebar, hear the sound. Load the applet in firefox on Linux. Hit the spacebar, hear the sound.
Now put the cursor in the address bar.
On Windows, push the button, hear the sound. Press the spacebar, hear the sound.
On Linux, push the button, hear the sound. Press the spacebar, ..... oops! No sound. The problem was reported to Sun two years ago.
I like Java. I like Java a LOT. But by no stretch of the imagination does it "just work."
Aah, change is good. -- Rafiki
Yeah, but it ain't easy. -- Simba
SOA is just OOP or modular programming come again, with network latency added in. It's useful (I wouldn't build a huge website without it), but it should be easily understood by anyone who's done software design before. Its problem is people hyping it up like it's a new paradigm when it isn't.
I still have more fans than freaks. WTF is wrong with you people?
Sound in Linux is a PITA in any language. If I was starting to diagnose this issue I wouldn't have started by blaming the VM.
XML is a known as a key material required to create SMD: Software of Mass Destruction
Ok, you are probably absolutely right. However, no one cares at all about applets. 99% of all written java code is pure server side and where it absolutely shines. If you are still bringing up applets when downtalking Java you have either not used the language in 10 years or you are just trying to put it in bad light on purpose.
right on! more like Same Old Anus for wont of a wanky TLA...
if you're going to design a service platform, design a freaking service platform - if you're going to build a service-based business, well then build a f*cking service-based business. if your legacy sh*t is sh*tty and holding you back from where you want to be well then rip it out. no need to apologise. no need to look to some enterprise-grade apologist for the magic bullet, there isn't one...
trolling the first world...
You're blaming Java because Linux sound sucks?
I use Ubuntu daily and I don't think a day goes by without me cursing the names ALSA and PulseAudio.
Especially PulseAudio.
Mod me down, my New Earth Global Warmingist friends!
A thought: I just read that slashdot post about brain slicing. Maybe the parent was written by H.M.? (The "slicee") Notice how it gets weirder and weirder - slice by slice?
you really think this is anything to do with sound? make the action something visual - same effect.
"We returned the General to El Salvador, or maybe Guatemala, it's difficult to tell from 10,000 feet"
Java is fat and gay.
I've been writing Java web service, web applications, and client applications for more than six years now. My current project runs on Solaris servers in about eighty countries around the world. My development environment for work is Windows and at home I use Linux. In all that time I've only run into one JVM issue that was specific to a platform (issue on Solaris JVM that caused it to just quit, which we worked with Sun to get fixed). I'm not saying "write once" is perfect, but it's so damn solid that I don't even give it a second thought.
...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.
I suppose the world would be a better place if we could all just agree on the One True Language instead of using different languages for different jobs or thinking about problems in different ways or playing around with different ways of implementing ideas? The languages you mentioned (PHP, Ruby, Python, VB, Perl) have very little in common except being interpreted. Although I understand the desire for a standard, it's as hard to see everyone agreeing on a single programming language, and its hard to buy the argument that the many languages available is hurting the web in any way. I could make the same argument about application development, but people still manage to do it.
Languages aren't inherently fast -- implementations are efficient
"I just don't trust anything that bleeds for five days and doesn't die."
Wow! Nice stealth misogyny, dude!
It would be impossible to get everyone to agree on the ONE language, that is a given, just look at the arguments of "pure" C -v- C++ -v- anything else so yes I agree. I think the problem boils down to project management mostly. I mean there is nothing generally wrong with any of them ( my own pet peeve is Python but I digress), each have their pluses and minuses so I think my chief complaint is walking into a project that is implemented in a smörgåsbord of languages, there is some Perl here, some Java there a little Python someplace else and throw in some PHP and a pinch of Ruby just for fun. Likely as not a lot of the original authors are gone and you just have a mess, albeit a mess that works, but a mess never the less. Poke it in the wrong place and the whole thing comes crashing down.
Hey KID! Yeah you, get the fuck off my lawn!
It is your right to disagree, but the level of vitriol with which you wrote your post is really uncalled for. Might I respectfully suggest that you might be taking this a little tiny bit to personally? I understand passion about anything, but really you were pretty over the top.
Wow... pot, meet kettle.
XML is a known as a key material required to create SMD: Software of Mass Destruction
Uh, you forgot the last line of your post:
"Get off my lawn, you damn kids and your rock and roll music, social equality and your high level programming languages!"
Mod me down, my New Earth Global Warmingist friends!
SOA is good for connecting desktop applications to web browser.
I'd like to buy homeland for our 10 million people. http://twitter.com/mahadiga
Hopefully it's because you have cancer.
???
Mod me down, my New Earth Global Warmingist friends!
they are talking about Service Oriented Architecture and that translates to the WWW
This is factually wrong, and is a pretty good example of the sort of "talking about something you don't understand" problem that readers have with your post.
Is it? Cloud computing, it is all the rage, it is Software As Service, it is rent me version of software and then there is this Wikipedia article that does seem to support my assertion. As to the main point of me being any of the rather derogatory you used, the reply was keenly about Java, less about SOA, and any amount of research does support my assertions that while Java is a great idea, in practice it is just as problematic as any other language as far as cross platform use goes and as for the various implementations of Java VM's ( of which there are no less then 30 I submit is is even more problematic. I for one am quite happy to have GCC on Linux as it is pretty much the same ( with a very few exceptions ) from distro to distro.
Hey KID! Yeah you, get the fuck off my lawn!
Not so much.
I do however completely agree with your sig.
Hey KID! Yeah you, get the fuck off my lawn!
they are talking about Service Oriented Architecture and that translates to the WWW
This is factually wrong, and is a pretty good example of the sort of "talking about something you don't understand" problem that readers have with your post.
Is it? Cloud computing, it is all the rage, it is Software As Service, it is rent me version of software and then there is this Wikipedia article that does seem to support my assertion.
The fact that Web mashups make use of SOA does not mean that SOA 'translates to' WWW.
You could build a whole enterprise around SOA principles, without a single Web browser being involved. Possibly without HTTP being involved. One very robust way of doing enterprise SOA is for your clients and services to talk to each other over some asynch messaging protocol (JMS, Apache ActiveMQ, Websphere MQ, etc.)
Microcode is slow and useless. I only arrange logic gates by hand. (Check out my fancy new word processor, coming in January 2490!)
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.
Aah, change is good. -- Rafiki
Yeah, but it ain't easy. -- Simba
Hence the verification that the sound is working before clicking away. It's a little trick that professional call "verification of test setup."
Aah, change is good. -- Rafiki
Yeah, but it ain't easy. -- Simba
Java's boyfriend coos: "Noooooo"
Hence the verification that the sound is working before clicking away. It's a little trick that professional call "verification of test setup."
It's not quite that easy. I have lots of apps where sound works fine on my laptop (Ubuntu 9.10), and others where it either doesn't work at all or all I get is white noise. Oh... and thanks for not being condescending, it really made my day.
XML is a known as a key material required to create SMD: Software of Mass Destruction
and you are?????????? silly comment, please stop it dude.
I read a paper on SOA once. It might as well be titled how to prevent small rocks from crashing into our Sun.
So you base your opinion on reading a paper on SOA once? Amazing.
Anything that uses XML for RPC and has no concept of distributed transactions (Compensation) rightfully deserves to continue its steady march into irrelevent obscurity
1. XML for RPC, why not? It's just a freaking format for transporting stuff. I know there are obvious problems with the bulk of WS-*, but there is nothing inherently wrong with using XML for RPC in certain contexs
2. Distributed transactions are an academic/vendor/architect astronaut white elephant, the solution for very extreme, fringe scenarios where simultaneous ACID properties over distributed resources is actually needed more than scalability. They aren't scalable, they are hard to reason with, and this is why no one that has to deal with massive scalability and availability requirements uses them.
If it doesn't at least support distributed transactions its not worth wasting ones time over.
Uh, why would an enterprise architecture style provides for transaction management, which is an application-specific feature. Distributed transactions are not even an infrastructure feature. No one worth mentioning uses them, and almost everyone that uses them didn't need them in the first place. This is why people in the trenches opt for compensating (rollback) transactions and "sagas" over distributed transactions. And this is not "news", so I don't know from what kind of work experience you keep talking about distributed transactions as the make-or-break factor in deciding over SOA... or anything for that matter.