0

I'm working on a SOA project based on SOAP. Well, i read many tutorials on Internet, but i still have the same problem, which is all articles & blogs, even the official documentation of eclipse told you how to use the IDE assistant or such APIs & frameworks (e.g : JAX-WS, CXF) to create a web service and gives you as bonus some definitions of SOAP, WSDL & UDDI, but none of them explained how an SOA works, the process of publishing & deploying a WS is done & how the C/S req/resp process of invoquing a distant web service is done using all these entities SOAP, WSDL & UDDI and the other files which exist in a SOA project (XML files & java files). I have read many e-books but still don't understand how SOA works. pliiiz i need your help guys, i'm really disturbed & confused. Many thanks in advance.

ayoubuntu
  • 425
  • 1
  • 8
  • 13

2 Answers2

10

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:

DISCOVERY

MESSAGING

META-DATA

SECURITY

QUALITY OF SERVICE

(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:

  1. Reusable in other applications or domains
  2. Makes its core functionality extensible internally and accessible externally (especially over a network connection, i.e. HTTP)
  3. 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
  4. Able to provide metadata on demand to describe its inner workings, making it possible to automate its integration
  5. 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.

bcmoney
  • 2,889
  • 1
  • 24
  • 30
  • 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! – reinierpost Dec 13 '12 at 18:25
  • 1
    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. – bcmoney Dec 13 '12 at 21:35
  • @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. – reinierpost Dec 18 '12 at 14:16
  • 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" http://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). – bcmoney Dec 18 '12 at 17:36
  • 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. – bcmoney Dec 18 '12 at 17:36
  • My point is that you are not excluding the use of a C library in your description, which I think means it isn't nearly specific enough. As far as I can see, what you state is that SOA is well-architected modularization. It may not be what you have in mind but it's what the words say. But not every module is a component and not every component is a service, by how most people use these words (and I don't mean to say they use them in the same way). – reinierpost Dec 20 '12 at 09:15
2

Looking at SOA as a set of this or that technologies is wrong. I also don't agree that SOA is just a marketing term, though it did get bad reputation and was muddled down by marketing and hype.

Service Oriented architecture is an architectural style. as in a blueprint for an architecture that possets constraints on how and what services should be asa well as define a set components and defines their interactions. The diagram below shows SOA vs. REST and you can see that they are derived from some common styles (e.g. they both build on client/server) but also arrive from different styles where SOA builds on pipe and filters and REST does't (you can build RESTful SOAs but you have to work harder :)) enter image description here

SOA puts a lot of emphasis on the interface. So unlike OO, for example, you have 4 different components that define an interface. The messages, the contract which bundles messages, endpoints where the contracts are delivered and policies that govern how/when contracts are deliverd.

enter image description here

Building services with well defined boundaries & good granularity (that's the tricky part) lets you compose services in a flexible way that lets you implement business capabilities faster. Pardon me for banging my own drum but you can read more on what's SOAand REST vs. SOA in chapter 1 and chapter 10 of my book on SOA patterns

Arnon Rotem-Gal-Oz
  • 25,469
  • 3
  • 45
  • 68
  • Yeah, I suppose simplifying SOA down to marketing hype is unfair, rather I should have said this simple concept has been rendered over-complicated by the SOA vendors who produce and promote their many technologies & tools as being the only pathway to achieving SOA. I really like your second diagram here, because it is more specific to what defines SOA and a picture tells 1000 words. For the first diagram though, I think it could be argued that you can draw arrows from "Distributed Agents" and "Pipes and Filters" to REST as well, albeit as you said, it requires more work to get there. – bcmoney Dec 14 '12 at 15:10
  • The four architecture styles that derive REST weren't defined by me- they- that's how REST is defined by Roy Fielding see his dissertation http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm – Arnon Rotem-Gal-Oz Dec 14 '12 at 15:34