Re: [service-orientated-architecture] John on Gartner, AJAX & Assorted TLAs

Thu, 24 Aug 2006 09:40:23 -0700

I don't think anyone was really suggesting pen and paper.

The move towards service orientation has always been about decoupling and hiding the implementation - or removing the burden from a consumer to have to deal with service implementation details. 

We have seen, over the last decade or more, large SOA implementations using various technologies including the ones Anne mentioned below (COBOL/CICS and PLI/IMS). And others with Java, CORBA, proprietary messaging systems and languages. 

And when you consider some other innovations like REST and the rise in dynamic languages and Web 2.0 you begin to wonder if OO's importance might be in decline (though many dynamic/scripting languages support object orientation). I'm not saying OO is in decline and I'm not saying it is a good thing that OO wold decline - before I get jumped on.

Today a service is more likely invoked on a URL or port or queue not an object. Behind the scenes it may very well be a well designed object oriented application. But for the consumer it's just a service. I mentioned in my blog some time back that we should see a rise in more procedural languages as service orientation moves forward. 

And that's great! To lock ourselves into one type of technology (including Java) doesn't exactly help foster innovation. Of course there is always the danger of reinventing the wheel. But we've been doing that for a few decades now in this industry ;-)


William [Not gone, just .... well trying to keep quiet ;-) ]

William G Henry
Enterprise Architect, Technical Director, Alliances    |    IONA Technologies Inc.

On Aug 23, 2006, at 8:01 PM, Gregg Wonderly wrote:

Anne Thomas Manes wrote:
> Gregg,
>
> Sorry, but I'm not following you. While I absolutely agree with the
> points you make below, I'm not sure what they have to do with the
> discussion as to whether services must be based on components. Folks
> have been extremely successful building highly reliable, performant,
> and scalable service-oriented systems using CICS/COBOL and IMS/PLI.
> Therefore I'm with Stefan. I see no reason why service orientation
> needs to be based on either components or objects.

Saying that SOA is not bound to a technology makes no sense. An SOA's software
components are bound to the capabilities of the technologies which create the
implementation. The SOA software system has no more capabilities,
maintainability nor usability with/by other software than the underlying
technologies allow.

If you design an SOA, have all of your business needs identified and supported
by the flow of the software systems (component based, object based or pencil and
paper based), but then try to implement with a software system that can't
adequately support the system design, the SOA will not meet all of your needs,
or perhaps it will meet none.

Thus, for me, there is a need to say it differently.

"An SOA doesn't have to use particular technologies to be viable. However
certain technologies might make an SOA more viable for a particular
implementation or use than others. So you still need to understand the value of
each system that is part of your overall SOA and how it enables or inhibits your
systems performance from each perspective that you might use to measure the
success of your SOA."

Some SOAs work great with just pencil and paper. Some need a computing device,
others need a network. Still others benefit from security (that doesn't involve
weapons) and even more benefit from the all important common communications
protocol.

Components and objects each have their benefits based on what type of system you
are implementing or interfacing with.

Sorry if I'm still not being clear enough about my view of the issue.

Gregg Wonderly


__._,_.___


SPONSORED LINKS
Computer software program Computer software spy Computer job
Database software Discount computer software

YAHOO! GROUPS LINKS



__,_._,___

Reply via email to