On 11/7/06, Eric Newcomer <[EMAIL PROTECTED]> wrote:
> 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.
>
I agree. Whole architecture of CORBA is around services. Standard
services are identified, application services can be expressed,
advertised and located in standard manner et. And all are decoupled.
If I remove the word object I think CORBA RM becomes first class
candidate for SOA RM. Als with following difference.
Like in MDA from PIM we generate PSM and then execution model, how
about If I say model PIM around business process/services using BPMN.
Then have translation to UML and then to execution model. And you have
this model called SOA RM? 3 layer architecture.
> 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.
>
This is another contentious issue. A service is advertised with its
QoS? In other words Service is advertised with its characteristics
that off-course is dependent on its execution environment, or service
is independent of its execution environment? In this case service
description is not complete. As we can't predict now its availability,
reachability, response time, queau length etc.
--
---------------
regards,
shashank d. jha
e-mail [EMAIL PROTECTED]
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/service-orientated-architecture/
<*> Your email settings:
Individual Email | Traditional
<*> To change settings online go to:
http://groups.yahoo.com/group/service-orientated-architecture/join
(Yahoo! ID required)
<*> To change settings via email:
mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
<*> To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
