On 6/13/07, Steve Jones <[EMAIL PROTECTED]> wrote:
>
> This is again where I have a bit of a conceptual issue. When I've done WS,
> CORBA, Messaging, Sockets, RSS, people or whatever then I've always
> thought of the service specific interface (e.g. when helping companies define
> their warehouse/truck interactions) for the business services being developed.
>
> So sure there is the implementation pattern, but at a business level there is
> pretty much always (I've not come across places where there aren't, but they
> may exist) service specific interfaces. The way you interact with procurement
> is fixed, the way you get your security badge is fixed and these things are
> always fixed to the service. These business interfaces are very rarely (again
> I've never seen one) uniform in the same way as JMS or REST are uniform.
>
> So if the goal is to deliver IT that looks like and operates like the business
> then ultimately it must be presented in service specific ways. This doesn't
> mean that the underlying technology implementation has to be RPC/Message
> based/REST/people or whatever, but it is important to understand the different
> challenges of business operations and technical realisation. Service specific
> interfaces are the reality of business and we don't want to pretend they don't
> as we pursue our technical solutions.
>
Spot on. The interface that you supply to the users of a system should
be focused on usability -- making the system as intuitive and
efficient as possible. But that doesn't mean that the underlying
technology has to reflect the user interface. (Remember: clean
separation of concern between interface and implementation.)
Even Mark agrees (from another response in this thread):
Furthermore, I suppose we should stop even talking about RPC in the
context of software architecture because whether a system uses it or
not, matters not to the architecture of that system.
This is one of the biggest learning curve challenges associated with
adopting REST. Developers naturally assume that the interface to
backend resources should correspond to the human interface. But it
doesn't need to. They also assume that the invocation interface to the
backend resource should correspond to the object model. But again, it
doesn't have to.
Let's say for example you have a service that manages information
about people. A service-specific interface would expose interfaces
like:
person getPersonByName("anne")
person[] getPeopleByAge("29")
and a service-specific POX representation of these methods would be
something like:
GET http://example.org/getPersonByName?name=anne
GET http://example.org/getPeopleByAge?age=29
A RESTful interface would be more like this:
GET http://example.org/people/anne
GET http://example.org/people?age=29
Note that to truly exploit the power of REST (and in particular, the
"hypermedia as the engine of state" constraint), the response to the
query by age should return a list of URIs for the people matching the
query (each person is a resource with its own URI).
Note also that the same application implementation could expose both a
service-specific interface and a RESTful interface is you wanted to.
That's the beauty of abstraction. It's not that hard to map a RESTful
interface to an object-oriented system. But does require thought to do
the mapping, and I'm not convinced it could be mapped automatically.
Anne
>
> On 12/06/07, Stefan Tilkov <[EMAIL PROTECTED]> wrote:
> >
> > Web Services, CORBA and RMI are not the same, but they share the
> > notion of a service-specific interface.
> >
> > Message Queueing, REST, Tuple Spaces and Relational Databases share
> > the notion of a uniform/generic interface.
> >
> > It's valid to distinguish these two groups and their respective
> > merits based on this distinction.
> >
> > Using the term "RPC" for the first style, though, is misleading - by
> > its very name, RPC is a programming model that tries to make a
> > (remote) network interaction appear like a (local) procedure call.
> > It's perfectly possible - and in fact the approach taken by more
> > recent WS implementations - to do service-specific interfaces without
> > an RPC-style programming model.
> >
> > IMO, using the label "RPC" for architectures that use service-
> > specific interfaces is simply a bad idea, unless one wants to start a
> > meaningless argument.
> >
> > Stefan
> > --
> > Stefan Tilkov, http://www.innoq.com/blog/st/
> >
> >
> > On Jun 12, 2007, at 7:33 PM, Mark Baker wrote:
> >
> > > On 6/12/07, Sanjiva Weerawarana <[EMAIL PROTECTED]> wrote:
> > > > Mark Baker wrote:
> > > > > On 6/11/07, Gregg Wonderly <[EMAIL PROTECTED]> wrote:
> > > > >> Not all RPC systems are CORBA systems.
> > > > >
> > > > > No, but all systems which expose service-specific interfaces
> > > are RPC systems.
> > > >
> > > > Your turn to be over-zealous?
> > > >
> > > > I assume you've looked at WSDL 2.0 right? Suppose a service
> > > offers an
> > > > interface with a bunch of In-only MEPs and maybe some more
> > > complex MEPs. A
> > > > client using that service does not necessarily have an RPC style
> > > > programming model.
> > >
> > > Are those interfaces the same? If not, then it's RPC.
> > >
> > > > RPC is a programming model which can be applied on any underlying
> > > > infrastructure. Its not an intrinsic property of an interface
> > > offered by
> > > > the service but rather a fairly popular programming model
> > > employed by clients.
> > >
> > > RPC isn't a programming model, it's an architectural style. If it
> > > were a programming model, then it wouldn't be externally observable,
> > > which it clearly is.
> > >
> > > As for Eric's comment about document-oriented Web services, I'd ask
> > > him to be a bit more specific because I've seen at least two different
> > > architectural styles go by that name. One is indeed not RPC because
> > > it adopts a single uniform connector (with only the application
> > > semantics of POST ("process this")). The other use is the so-called
> > > "document encoding", which is just RPC.
> > >
> > > Mark.
