I agree: Anne has stuck with SOA. Other analyst groups and vendors, whom I need not identify, have come up with many derivatives of SOA, e. g., SOBA, SODA, SOEA, SOTA, SOMA, SODC, AE/UDC, O-DC, RTE, ZLE, and other nonsense.
M. R. Pamidi
-----Original Message-----
From: JP Morgenthal <[EMAIL PROTECTED]>
To: [email protected]
Sent: Sun, 30 Oct 2005 08:50:57 -0500
Subject: RE: [service-orientated-architecture] Re: What is a Service? What is an Application?
With all due respect to Anne (who is one of the few practicing analysts) SOA and other horrible terms in our industry is what comes of analyst groups and vendors defining the terminology that the industry uses.
In essence, SOA does not exist at all, because it represents nothing but a marketing catch-all for a way to develop applications using Internet standards and Web protocols as the underlying infrastructure. Some vendors are now trying to leverage that catch-all to say that the older way of building distributed applications now needs to be factored back in.
JP
| ||||||||||||||
|
| ||||||||||||||
From: [email protected] [mailto:[email protected] ] On Behalf Of Keith Harrison-Broninski
Sent: Sunday, October 30, 2005 4:45 AM
To:[email protected]
Subject: Re: [service-orientated-architecture] Re: What is a Service? What is an Application?
Sent: Sunday, October 30, 2005 4:45 AM
To:
Subject: Re: [service-orientated-architecture] Re: What is a Service? What is an Application?
Yes, I know what you meant, Anne - I expect most of us do - my point was that your definitions don't capture your intentions, any more than the other hundreds of such definitions people have posted here over the last few years. And I am sorry for singling your post out for attack! I did so since you personally have enough credibility amongst us not for it to matter :-) .
I recently re-read a book that inspired me as a maths undergraduate: "Proofs and Refutations", by Imre Lakatos - a very amusing, slim and non-technical study of the nature of mathematical discovery, which I recommend to anyone. Lakatos shows that any proof can be invalidated by challenging the underpinning definitions in some way. So all definitions are innately vulnerable, aren't they. However, some are more vulnerable than others! The definitions of "service" and "application" that we explore in this group are so vulnerable that it points to a deeper problem.
The reason I personally joined this group is not because I have a particular interest in (say) Web services or Jini, though I use both technologies and try to keep up with developments. I joined since SOA is in the vanguard of developments in programming technology, along with aspect-oriented programming, test-first programming, model-driven development, extensible frameworks, and other powerful modern approaches (there have been a lot recently). But SOA is really not about something called a service at all - a concept which IMHO doesn't exist. SOA is about ways to implement distributed software systems. Unlike some of the other examples given previously, this is not a new idea at all, but we are making strides at the moment for various reasons.
So I suggest that the deeper problem is that "service oriented architecture" is a misleading term. A better one would be "distribution oriented architecture". Although the acronym might put some CIOs off an implementation project :-)
I recently re-read a book that inspired me as a maths undergraduate: "Proofs and Refutations", by Imre Lakatos - a very amusing, slim and non-technical study of the nature of mathematical discovery, which I recommend to anyone. Lakatos shows that any proof can be invalidated by challenging the underpinning definitions in some way. So all definitions are innately vulnerable, aren't they. However, some are more vulnerable than others! The definitions of "service" and "application" that we explore in this group are so vulnerable that it points to a deeper problem.
The reason I personally joined this group is not because I have a particular interest in (say) Web services or Jini, though I use both technologies and try to keep up with developments. I joined since SOA is in the vanguard of developments in programming technology, along with aspect-oriented programming, test-first programming, model-driven development, extensible frameworks, and other powerful modern approaches (there have been a lot recently). But SOA is really not about something called a service at all - a concept which IMHO doesn't exist. SOA is about ways to implement distributed software systems. Unlike some of the other examples given previously, this is not a new idea at all, but we are making strides at the moment for various reasons.
So I suggest that the deeper problem is that "service oriented architecture" is a misleading term. A better one would be "distribution oriented architecture". Although the acronym might put some CIOs off an implementation project :-)
-- All the bestKeith http://keith.harrison-broninski.info
Keith,
I respectfully disagree with you.
>> This definition [of service] covers operating system, device drivers and application servers - which I suspect are not services in the sense that members of this group use the term.
Operating systems and application servers aren't services, but they both provide many services. And an application interacts with those services through a service API. Device drivers are also services. Admittedly, these are infrastructure services -- but they are still services. Services can supply business and/or infrastructure functionality. Typically applications access low-level infrastructure services through higher-level framework services. But they are still all services.
>> An ERP application doesn't [implement and automate a discrete business process- - it may cover many or none in totality. And, at the other end of the scale, what about an application for editing audio files?
An ERP application system comprises a great many applications -- each of which implements and automates a discrete business process. An application for editing audio files implements and automates a discrete business process (enabling, capturing, and persisting edits to the audio file).
Anne
I respectfully disagree with you.
>> This definition [of service] covers operating system, device drivers and application servers - which I suspect are not services in the sense that members of this group use the term.
Operating systems and application servers aren't services, but they both provide many services. And an application interacts with those services through a service API. Device drivers are also services. Admittedly, these are infrastructure services -- but they are still services. Services can supply business and/or infrastructure functionality. Typically applications access low-level infrastructure services through higher-level framework services. But they are still all services.
>> An ERP application doesn't [implement and automate a discrete business process- - it may cover many or none in totality. And, at the other end of the scale, what about an application for editing audio files?
An ERP application system comprises a great many applications -- each of which implements and automates a discrete business process. An application for editing audio files implements and automates a discrete business process (enabling, capturing, and persisting edits to the audio file).
Anne
On 10/29/05, Keith Harrison-Broninski <[EMAIL PROTECTED]> wrote:
Here's a definition for "service" that I've been using for about 4 years:
A service is a piece of software that does work for other software. A service typically exposes its functionality to other software via an application programming interface (API). Software functionality is typically factored into a service so that it may be shared by multiple applications. For maximum reusability, the service should be design according to service-oriented architecture (SOA) design principles, and the service API should be described using standard metadata languages and implemented using standard protocols.
A service is a piece of software that does work for other software. A service typically exposes its functionality to other software via an application programming interface (API). Software functionality is typically factored into a service so that it may be shared by multiple applications. For maximum reusability, the service should be design according to service-oriented architecture (SOA) design principles, and the service API should be described using standard metadata languages and implemented using standard protocols.
This definition covers operating system, device drivers and application servers - which I suspect are not services in the sense that members of this group use the term.
And here's my corresponding definition for "application":
An application implements and automates a discrete business process.
An application implements and automates a discrete business process.
An ERP application doesn't - it may cover many or none in totality. And, at the other end of the scale, what about an application for editing audio files?
If definitions provided by someone of Anne's universally acknowledged caliber don't hold water, surely there is something rotten here. This group has gone round the definition of "service" and "application" so many times now that I've lost count! I think Ron had it right at the start - this is a time-wasting exercise. What might be an interesting question, on the other hand, is: why can we not agree?
Perhaps there is no such thing as a "service" at all, and when we discuss SOA we're just talking about the latest steps in the move towards software modularity that began 40 years ago ...
If definitions provided by someone of Anne's universally acknowledged caliber don't hold water, surely there is something rotten here. This group has gone round the definition of "service" and "application" so many times now that I've lost count! I think Ron had it right at the start - this is a time-wasting exercise. What might be an interesting question, on the other hand, is: why can we not agree?
Perhaps there is no such thing as a "service" at all, and when we discuss SOA we're just talking about the latest steps in the move towards software modularity that began 40 years ago ...
-- All the bestKeith http://keith.harrison-broninski.infoSPONSORED LINKS
| Service-oriented architecture | Computer monitoring software | Computer and internet software |
| Free computer monitoring software |
YAHOO! GROUPS LINKS
- Visit your group "service-orientated-architecture" on the web.
- To unsubscribe from this group, send an email to:
service-orientated-architecture-unsubscribe@yahoogroups.com
- Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
SPONSORED LINKS
| Service-oriented architecture | Computer monitoring software | Computer and internet software |
| Free computer monitoring software |
YAHOO! GROUPS LINKS
- Visit your group "service-orientated-architecture" on the web.
- To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
- Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
