Hi folks. Comments in-line. On Mon, 2006-07-17 at 10:40, Harm Smit wrote: > -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.
This is true, however the danger of concluding that this service must be explicitly referenced via a lightbulb10.turnOn() type invocation inherently ties your service requester to a *specific* location provided by a *specific* service provider. To me, this resolution should be part of the plumbing to allow interventionist actions like service provider selection based on policy or deployment configuration rather than making the explicit decisions in your requester implementations. This is where you start to get real value from loosely coupled SOA implementations. > 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. This is true, and is one of the issues with not including location as one of the loose coupling dimensions in your architecture. > 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. I do agree with the first part of what you're saying because you're stressing the abstract interface may be implemented by more than one provider. Fair enough, but you shouldn't tightly couple a given service provider into your requester application based on your service implementation having the knowledge of which one you want to invoke today--even if you do it with a simple configuration parameter stored in a flat file. This is the main driver behind configuration vs. coding, and is one of the main reasons you have to have well-defined layers within your service implementation and infrastructure so you can include these capabilities. You can say this is a characteristic of an ESB, and this is certainly one example, but in a more general sense, it's simply providing implementations of the Interceptor pattern from POSA2. > 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. Your service invoker implementation should not know, but your deployed solution must certainly know the difference and under which circumstances each should be invoked. The function and the deployment can quite happily vary independently from each other. I do want to touch briefly on something Anne mentioned. Maybe this has been beaten to death (I haven't had a chance to participate in this forum for a while), but I think it's worth mentioning. > -----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. I think the last comment is mixing implementation with architecture. There's certainly nothing about using a resource-oriented approach that says I'd define a separate service for each resource. That would be an incredibly naive way to implement it. If you had resources that looked like: http://host/stocks/IBM http://host/stocks/ORCL http://host/stocks/MSFT or http://host/stocks?symbol=IBM http://host/stocks?symbol=ORCL http://host/stocks?symbol=MSFT you would still more than likely have one service that implemented it and provided the given interface. Different hosts may offer the same interface at a different URL, but there's still an implicit service contract involved if you want to preserve interoperability between them. In this degenerate case, you could even argue that your service requester shouldn't even need to know or care which of the above was used or if it was a SOAP call because they should really only be concerned with the message body. This approach is the basis of our concept of a business-level envelope. I'm not saying that there aren't other issues involved in choosing a REST approach vs. anything else, but what I am saying is that for simple services providing a synchronous lookup based on an input parameter, it can be implemented using appropriate layering and encapsulation to make no difference to the caller at all. To the service provider, it may make a huge difference to the infrastructure required as well as scalability and caching characteristics. The bigger question is whether you would/should expose such an interface within your architecture at all based on your overall objectives and the other services you intend to provide. ast *************************************************************************************************** The information in this email is confidential and may be legally privileged Access to this email by anyone other than the intended addressee is unauthorized. If you are not the intended recipient of this message, any review, disclosure, copying, distribution, retention, or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you are not the intended recipient, please reply to or forward a copy of this message to the sender and delete the message, any attachments, and any copies thereof from your system. *************************************************************************************************** Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/service-orientated-architecture/ <*> 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/
