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.
