Again, I respectfully disagree:
>> 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.
While you can certainly use service-oriented technologies to implement distributed systems, what you get out of those efforts will not be service-oriented systems unless you actually adopt service-oriented design principles.
>From my perspective (and I realize that lots of people disagree with me on this point), the essential concept in SOA is reusability. And service-oriented design principles (SODP) focus on enabling reusability. The essential principles of SODP are loose coupling, interoperability, abstraction of interface from implementation, abstraction of implementation from infrastructure, and proper granularity of function.
As Jan points out, you can't effectively define an architecture without articulating the constraints of the architecture. These high-level design principles provide some vague constraints, but the challenge we have is that we need much more specific design principles and architectual constraints. It would also help to have some established design patterns. But you can't distill design patterns until you have some experience working with the design principles.
SOA is very similar to the distributed object architecture we've used for the last 15 years, but the context is slightly different -- therefore the design patterns that work with DO don't necessarily apply to SO. And unfortunatley for us now at this time, it will take us some time to work through the concepts and figure out what works.
Anne
On 10/30/05, Keith Harrison-Broninski <[EMAIL PROTECTED]> wrote:
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 :-)
--
All the best
Keith
http://keith.harrison-broninski.infoAnne Thomas Manes wrote: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
On 10/29/05, Keith Harrison-Broninski <[EMAIL PROTECTED] > wrote:Anne Thomas Manes wrote:Here's a definition for "service" that I've been using for about 4 years: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.
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.
And here's my corresponding definition for "application":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?
An application implements and automates a discrete business process.
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 best
Keith
http://keith.harrison-broninski.info
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.
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.
