<<The votes are in and the Reference Model for Service-Oriented Architecture 1.0 has been approved as a standard by OASIS, a spokesperson for the standards body confirmed Monday. An official announcement is expected later this week.

The SOA-RM is intended to define the term clearly and technically for developers and architects. It might be hoped that the new standard will keep SOA terminology from being hijacked by software marketers eager to make sure their latest product release is buzz-word compliant whether or not it has anything to do with the service-oriented approach to application development.

The OASIS technical committee that worked on SOA-RM described it as "an abstract framework for understanding significant entities and relationships between them within a service-oriented environment, and for the development of consistent standards or specifications supporting that environment. It is based on unifying concepts of SOA and may be used by architects developing specific service-oriented architectures or in training and explaining SOA."

SOA-RM is not "directly tied to any standards, technologies or other concrete implementation details," the committee said. Rather, its purpose is described as providing "common semantics that can be used unambiguously across and between different implementations."

However, developers seeking specifics on how to implement SOA will have to look elsewhere, said Jason Bloomberg, senior analyst at ZapThink LLC.

"The OASIS SOA Reference Model is an abstract model that is intended to help organize distributed capabilities across different sets of users," the analyst said. "In essence, the SOA-RM is intended to help enterprise architects coordinate separate SOA efforts across an organization. The challenge that SOA-RM has is that it's quite abstract. So it can provide an overall framework for planning an enterprise SOA initiative, but it won't provide much in the way of real-world SOA implementation advice."

Duane Nickull, senior strategy analyst, Adobe Systems Inc., who worked on the technical committee crafting SOA-RM during the past 16 months, said that while he has heard the criticism that it is too abstract, the new standard is already being used in SOA implementations.

"Part of the process of becoming an OASIS standard is that you have to have submissions by member companies that have been using it in production," he said. "There are supposed to be three and we had way more than three."

Even for those who have somewhat differing views of what would make a definition of SOA, Nickull sees SOA-RM as a positive step in the architecture's evolution. "What some people have pointed out who have slightly differing opinion of SOA is that they like it because even if you disagree with it, you can point to it and say, 'When I say SOA I mean that.' They know we've quantified SOA as an architectural paradigm and a model that was needed."

SOA-RM has even achieved the ultimate is Web 2.0 recognition. Nickull said, "It's included in wikipedia.">>

You can read this at:

http://searchwebservices.techtarget.com/originalContent/0,289142,sid26_gci1224904,00.html?track=NL-110&ad=568336&asrc=EM_NLN_643237&uid=5532089

 

 

Gervas


From: [email protected] [mailto:[email protected]] On Behalf Of Michael Poulin
Sent: 16 October 2006 22:26
To: [email protected]
Subject: Re: [service-orientated-architecture] What is SOA?

 

Gregg wrote: " 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. "

I am looking for an advice: how much "minimal amount of software" is needed to solve a problem of developing a software for the changes in the enterprise business model (not changes in subjective L&F or in amount of transactions per second passed through a B2B channel)?

BTW, I do respect Jini and also know it has a LOT of infrastructure. Plus, I am interested in knowing what Jini solutions (like 'mobile code') could be used outside of the Jini platform?

- Michael Poulin


Gregg Wonderly <[EMAIL PROTECTED]> wrote:

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

 

 


Get your email and more, right on the new Yahoo.com

__._,_.___


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

__,_._,___

Reply via email to