Harm,
The discipline of SOA certainly wasn't created in a vacuum and takes a lot from its predecessors. The shift and clarification in emphasis away from technology and towards contracts carries new ideas and refinements to old ones, but advanced practitioners were definitely applying such concepts with mid-late 1990's technology, in pockets.
With regards to instantiation, most distributed object systems in commercial settings that I'm aware of did not take advantage of unique object identity in this way , except for the early pioneers that weren't aware of the scalability challenges. In practice, either you instantiated it once and passed an IOR around, or you instantiated it each time, depending on your ORB. The distributed object was effectively used as a stateless service, similarly an EJB stateless session bean. In MTS/COM+ or DCOM this was the standard approach, and in CORBA it was common if you wanted to get any sort of scalability.
Granted, distributed objects != services, but this is not to say you cannot build an SOA on top of distributed object technology with a certain set of constraints. Having said this, most did not govern their interfaces to the needed level to gain a level of increasing returns through consistency. Nor could you develop a rich cross-platform data model without custom marshalling.
But there were cases where an organization did govern their interfaces and data formats to a reasonable level and gained some agility & marginal cost benefits due to that consistency (even if they didn't call it SOA at the time), and I've seen this with EJB, C++ CORBA, and C++ COM, though only in departmental or divisional pockets -- not organization wide.
Cheers
Stu
The discipline of SOA certainly wasn't created in a vacuum and takes a lot from its predecessors. The shift and clarification in emphasis away from technology and towards contracts carries new ideas and refinements to old ones, but advanced practitioners were definitely applying such concepts with mid-late 1990's technology, in pockets.
With regards to instantiation, most distributed object systems in commercial settings that I'm aware of did not take advantage of unique object identity in this way , except for the early pioneers that weren't aware of the scalability challenges. In practice, either you instantiated it once and passed an IOR around, or you instantiated it each time, depending on your ORB. The distributed object was effectively used as a stateless service, similarly an EJB stateless session bean. In MTS/COM+ or DCOM this was the standard approach, and in CORBA it was common if you wanted to get any sort of scalability.
Granted, distributed objects != services, but this is not to say you cannot build an SOA on top of distributed object technology with a certain set of constraints. Having said this, most did not govern their interfaces to the needed level to gain a level of increasing returns through consistency. Nor could you develop a rich cross-platform data model without custom marshalling.
But there were cases where an organization did govern their interfaces and data formats to a reasonable level and gained some agility & marginal cost benefits due to that consistency (even if they didn't call it SOA at the time), and I've seen this with EJB, C++ CORBA, and C++ COM, though only in departmental or divisional pockets -- not organization wide.
Cheers
Stu
----- Original Message ----
From: Harm Smit <[EMAIL PROTECTED]>
To: [email protected]
Sent: Monday, July 17, 2006 5:40:38 AM
Subject: RE: [service-orientated-architecture] Zapthink on SOA/REST
From: Harm Smit <[EMAIL PROTECTED]>
To: [email protected]
Sent: Monday, July 17, 2006 5:40:38 AM
Subject: RE: [service-orientated-architecture] Zapthink on SOA/REST
-1.
Anne, I don't know which "traditions" you are referring
to for a discipline that is only a few years old. Yes, I know we disagree on
this point: to you, CORBA and DCOM are also SOA -- to me, SOA is no older than
Web Services. But maybe this is precisely why we are diverging here: could
it be that your position is inspired by the heritage of the distributed object
paradigm? As the draft OASIS SOA Reference Model puts it in its
section "How is SOA different?": "To use an object, it must first be
instantiated, while one interacts with a service where it exists". IOW, in SOA
there is no notion of instantiation.
Furthermore, it seems to me that quite some confusion
stems from not distinguishing between abstract services and the actual
implementations thereof, through the corresponding service
providers.
Taking your stock quote example, let's assume there is
just one universal abstract stock quote service. But that doesn't mean there is
just one universal stock quote service provider, and one may have very good
reasons to prefer one service provider over another, e.g., because they don't
cover the same range of stock symbols.
Similarly, when invoking the services of a
smart lightbulb, I'd need to know whether it's the lightbulb in the kitchen
or the one in the bathroom. But both lightbulbs would implement the same
abstract service, even if they were from different vendors.
HTH,
Harm.
-----Original Message-----
From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of Anne Thomas Manes
Sent: vendredi 14 juillet 2006 20:06
To: [email protected]
Subject: Re: [service-orientated-architecture] Zapthink on SOA/REST+1. In a traditional service-oriented approach, a service implements a function that can be performed on multiple instances of a resource. You do not have a different service for each resource. .e.g, you have a stockQuote service -- you input a stock symbol and it returns the stock quote for that stock symbol. You don't define a separate service for each stock symbol. The latter would be a resource oriented approach -- and it makes much more sense to use a uniform interface( i.e., REST) when using a resource-oriented approach.
Anne
On 7/14/06, Stefan Tilkov <[EMAIL PROTECTED] > wrote:On Jul 14, 2006, at 9:52 AM, Harm Smit wrote:
> The latter is rubbish. It should read: lightbulb10.turnOn()
> Each lightbulb is an independent, autonomous service provider.That's the first time I've seen someone make that claim for SOA-style
services.
Stefan
--
Stefan Tilkov, http://www.innoq.com/blog/st/
SPONSORED LINKS
| Computer software | Computer aided design software | Computer job |
| Soa | Service-oriented architecture |
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.
