Re: [service-orientated-architecture] abstraction of soa and its components

[Eric Newcomer]

Hi Shashank,

 

I had a very similar reaction.  I don't think SOA is a paradigm.  I think service orientation is a paradigm, but SOA is more properly an approach or a style of design.

 

Also I think a service is a function more than a mechanism.  The implementation of a service needs to be separated from its definition to ensure any execution environment can be used for it (or maybe more than one).

 

I see that your email has created a lot of discussion, much of it about the alignment between business and technology that services and SOA promises.  I haven't read it all carefully so I don't want to comment on very much of it.

 

One thing I would like to add however is that SOA has been around for a long time, and what we are seeing today is the growing popularity of the approach.  Why now?  When SOA has been around for 10-15 years, why is it now popular?  Some say Web services provide cheaper, more widely adopted standards for it.  Web services also are service oriented, not object oriented, and this also helps.

 

However I believe the major factor is the maturity of the software industry such that the major problem facing business, industry, and government is no longer the automation of basic functions, but the improvement of this automation such that systems in place work better together. 

 

I believe the RM supports the distinction between execution environment and service description that is key to achieving this level of improvement, but as some have noted in other responses it is a product of a comittee consensus process and therefore probably not as clear as it could have been, but nonetheless representative of that broader consensus.  In other words, it is not the same as an article or book.

 

Eric

----- Original Message ----
From: shashank d. jha <[EMAIL PROTECTED]>
To: service-orientated-architecture@yahoogroups.com
Sent: Sunday, November 5, 2006 11:02:54 AM
Subject: [service-orientated-architecture] abstraction of soa and its components

hi all,

I was going through the reference model os soa by OASIS and I found it lacking seriously in most of the abstractions it talks about

Lets start with soa definition itself-
SOA- (SOA) is a paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains.

Till now my general understanding of soa was
SOA is an architectural approach that seeks to align business processes with service protocols and the underlying software components and legacy applications that implement them.

similarly abstraction of vocabulary execution context, visibility, real-world effect, interaction all seems to be too primitive, lacking in general high level abstraction.

At one point document says
  A service is a mechanism to enable access to one or more capabilities?

Is service a mechanism or end?

In the topic "Dynamics of service" it has used so many closely related and confusing terms like visibility, awareness, real-world effect, willingness, reachability etc.?

What is the general opinion of people here?


------------ ---
regards,
shashank

__._,_.___

SPONSORED LINKS

Computer software	Computer security software	Computer software program
Computer fax software	Computer virus software

Your email settings: Individual Email|Traditional
Change settings via the Web (Yahoo! ID required)
Change settings via email: Switch delivery to Daily Digest | Switch to Fully Featured
Visit Your Group | Yahoo! Groups Terms of Use | Unsubscribe

__,_._,___