Shashank D. Jha wrote: > On 7/23/07, Gregg Wonderly <[EMAIL PROTECTED] <mailto:gergg%40cox.net>> wrote: > > Shashank D. Jha wrote: > > > OO (Real world entities) principals were fundamentally different from > > > SOA (Industry's best practices for business agility) principals. they > > > were not developed to address enterprises IT concerns, but were to > > > address software development concerns. So same modeling concept is > > > limiting for a Service modeling. > > > > This comment seems to indicate that we should develop SOA software > solutions in > > Fortran, assembly language, or waving flags or some such. Please, can you > share > > with me exactly which part of OO technologies are not applicable to SOA? > > Most are applicable. you just mis-read my comments. I was telling > using OO to describe Service, is limiting to service description. > Example: Objects describe what services it provides, while hiding its > dependency on other objects, while components makes this dependency > explicit, by specifying not only what it provides but also what it > needs (service's dependency) this allows graphically representing > application/ assembly of components easy.
I am not sure I completely follow. If one service uses another service, that's part of such a service's documentation. It doesn't matter, whether you use the word Object in your documentation or not, you still need to say that another service provides something that your service needs, and therefore must be present. > But component definition is limiting to service description as the > governance/policies are not explicit in component definition. Governance and policies are deployment issues, not service description issues. If your programming language/environment/platform doesn't provide such separation of concerns, then you might have some issues/burdens to surpass in your development cycle, but you should keep the separated in your documentation. > Basically what it means that abstraction provided by an object is at > lower level than abstraction provided by a Service. I don't think this is true. I think it depends on how you decide to write the documentation and what words you choose to use. Gregg Wonderly
