wood burning stoves 2.0*
The moose likes Web Services and the fly likes Definition of SOA Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of OCA/OCP Java SE 7 Programmer I & II Study Guide this week in the OCPJP forum!
JavaRanch » Java Forums » Java » Web Services
Bookmark "Definition of SOA" Watch "Definition of SOA" New topic
Author

Definition of SOA

Silvio Esser
Ranch Hand

Joined: Nov 05, 2005
Posts: 58
I'm designing a service application that provides some services to other Java applications using RMI. My application needs to call other services (EJB and Corba) in the same enterprise. Can I say that I have a SOA architecture?

I know it is not Web Services.
Peer Reynders
Bartender

Joined: Aug 19, 2005
Posts: 2922
    
    5
Originally posted by Silvio Esser:
I'm designing a service application that provides some services to other Java applications using RMI. My application needs to call other services (EJB and Corba) in the same enterprise. Can I say that I have a SOA architecture?


Why is that important?

We're using C++ and Java on our project. Can I say that were are practicing Object-Orientation?

Not necessarily; and OO is much easier to pin down than SOA.

If you are claiming that you have an architecture that emerged from the application of SOA principles then you better be prepared to
  • Itemize what those principles are
  • Explain how those principles lead you to your current design/architecture.

  • (you could say there is no such thing as an "SOA architecture" )

    Here is a quick summary of what the SOA paradigm/approach tries to accomplish - at least according to Nicolai Josuttis' SOA in Practice: The Art of Distributed System Design.

    One of the key drivers of SOA besides distribution of processing and heterogeneity of the systems being integrated is the fact that the systems are under the control of different business owners (different companies, different departments; ultimately preventing a harmonized approach - though the vast scope the architecture under design can also play into this).

    The key SOA concepts (Services, High interoperability, Loose Coupling) also have numerous aspects and nuances. For example "loose coupling" always cames at a cost and you have to decide how "loosely coupled" you actually need to be - e.g. using two-phase commits (2PC) is actually a form of tight coupling, compensation is preferred in a "loosely coupled" environment.

    Also SOA is only concerned with enabling business processes. IT infrastructure and activities that do not directly relate to identified business processes (e.g. running system backups) SOA isn't interested in.
     
    Consider Paul's rocket mass heater.
     
    subject: Definition of SOA