Mark Baker wrote:
>
>
> On 10/10/06, Gregg Wonderly <[EMAIL PROTECTED] <mailto:gergg%40cox.net>>
> wrote:
> > Mark Baker wrote:
> > > How about a *testable* definition, Gregg? One that I can use to
> > > evaluate a system to determine whether it's architecture is SOA or
> > > not, as well as understand what changes I'd need to make for it to
> > > become SOA (including what advantages I'd gain in doing so).
> >
> > The test is this. Is it cheaper to keep doing things the way you are doing
> > them, or is it cheaper to create additional services that support
> automation and
> > decoupling of business processes from the systems.
>
> There are many ways to do that. Are all of them SOA? If not, can you
> be more specific? If so, are they all created equal, or are some
> better than others in the general case?
I think that there are architectural and technological features of different
systems that provide different ROIs. That's what we hash around on this group
about. That's what you need technically savey people to for. If you hire
someone who's good with Web services, you'll perhaps get a good web services
oriented solution. If you hire someone who's good with CORBA, you'll perhaps
get a good CORBA solution. If you hire someone like yourself, you'll get a
RESTarian solution.
I'm in the Jini camp, as you know, and I'd suggest that there are levels of
abstraction available in Jini, through mobile code, which are the key value
added, but which not many people really understand.
Many people seem to look at SOA technologies as solving "one" problem. Namely,
interoperability, linked with security. I contend that interoperability is a
trivial aspect of SOA. It's something that you do once. It's the security,
management, stability and ability to adapt to new needs which are the
evolutionary needs of software systems.
> Also, cost prediction is a soft science at best. Is there no way to
> decide whether something is SOA by simply looking at a description of
> the proposed architecture?
I think that there is a wide range of SOA definition, as we've beat around on
this list about. Ultimately, SOA, from my perspective, includes all the things
that Jini provides.
o Service discovery (A lookup/discovery service).
o Customizable security system (which deployers can use, not
just programmers).
o Transactional services (which are oriented toward optimizing
distributed use).
o Leasing/timeout based recovery strategies for distributed state
(including service registration).
o Persistent, distributed storage which has an API aimed at simple
data values, we already have SQL.
When you look at other SOA technologies, which are not Jini base, you'll see
that they include several other things, besides these things.
Additional, things are needed because of attributes of those technologies.
It's
the requirement for those additional things, that is the red flag for me.
But, I'm just a little bit of a minimalist. I really do believe that the
absolutely most minimal amount of software that I can come up with to solve a
problem is exactly the right solution for a problem. That's fewer bugs, fewer
reviews, fewer tests and fewer external dependencies. All of which, I've
found,
to be additional cost reducers.
Maybe you can elaborate about other/additional attributes of an SOA that you
think are important.
Gregg Wonderly
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/
