Don't get too hung up on that term Service Oriented Architecture (SOA) as its really more of a marketing term that describes a well-known and practiced software development methodology of making programs into specialized components that can be reused across a broad range of applications. It can also describe applying this software development methodology to business process modeling where business units and workflows are modularized and looked at as individual services rather than monolithic processes that exist in a bubble, and some call this different but related application of the concept Service Oriented Modeling.
While SOA shares a lot in common with modularization, it also adds the requirement that your separate code modules not only inter-operate and integrate (i.e. work well together with) each other, but potentially with everyone else's code in the world, and also that they are available over some well-defined mechanism.
An SOA "purist" might tell you that for your software to be "SOA-compliant" (note: that's not a real thing as there's no single set of rules or governing body on services) that you need to write it as a SOAP Web Service, publish and maintain a WSDL which can act as a contract between you and any implementing parties, and follow the relevant WS-* specs. However, in reality REST and other lightweight modularization/integration/reusability approaches are just as much in line with the concept of SOA.
If you did want to become an "expert" in SOA then read through every word of the following specs:
(those are just some of the most important WS-* specs, see full list here)
Then read every page of the following essential SOA books:
However, I don't actually advise that as there's way too much reading material. What I would suggest though, is that you use them as a reference as you code your own programs following an SOA methodology and notice that in a specific area, a reference manual on what to do next would come in handy. Practice makes perfect and you'll really learn a lot more from working with real-world examples than from reading books and learning everything about the standards and theory. As you mentioned, start with the overly-simplistic JAX-WS and JAX-RS Web Service examples that come out-of-the-box with IDEs like NetBeans or Eclipse, then try some examples that come with popular SOA frameworks like CXF, Axis2 or RESTlet.
In general, as you are writing code constantly ask yourself if your code is:
Reusable in other applications or domains
Makes its core functionality extensible internally and accessible externally (especially over a network connection, i.e. HTTP)
Provides output data or metadata in an easy to parse/process (and thus integrate) format like XML, JSON or one of the many related data languages and sub-languages
As specialized and modularized as possible; and at the same time, if there are other similar specalized APIs or Web Services that already exist out there, would it be better to use them instead of reinventing the wheel
There are lots of other questions and criteria that people may use, but IMHO these are the most important.
Great answer, but aren't you neglecting to mention the key point? It's not just about making programs from components, but from services: components that operate by listening for and answering requests over a network!
I'd argue that SOA as a methodology (as allueded to at the top of my answer) doesn't require a network to be applied as a concept, but yes I've updated my response to reflect that a network is usually involved.
@bomoney: So when a C program uses zlib for (un)compression support, it's doing SOA? Yikes - I've seen terminology dilution before, but never quite on this scale.
Wow, that's quite a leap... I didn't say that at all. The OP knows about SOAP/ws-* but was asking how they fit together to achieve SOA. What I did is list some common aspects of SOA to provide a high-level view and compare it to a simple Object-Oriented pattern namely "modularization" en.wikipedia.org/wiki/Module_pattern (which in my experience consulting for enterprises is a commonly sought-after SOA pattern, only in the form of Remote Procedure Invocation, Message Router and Event-Driven Consumer).
My point was for OP to take a step back and think about concepts they want to employ not just technologies. A C program using zlib has nothing to do with it... mind you if you were a sucker for punishment you could probably program an entire Enterprise Integration pattern into said strange form of C plus zlib compression/uncompression and call that SOA, being only partially a nutbar for doing things the difficult way, because the patterns themselves are technology agnostic.