Mark Baker wrote:
> On 7/7/06, Gregg Wonderly <[EMAIL PROTECTED]> wrote:
>>Mark Baker wrote:
>>>On 7/6/06, Steve Jones <[EMAIL PROTECTED]
>>>>What form of scalability are you refering to?
>>>
>>>Number of services. With Web services, for each new service that's
>>>added to the system, in order for existing components to be able to
>>>communicate with it, you have to modify them (ignoring the data issue,
>>>which is the same with both). Not so with REST.
>>
>>Last I checked, the use of any RESTful system component required knowlege of a
>>URL to select the resource. Are you considering that part of the "data is
>>same
>>for both" issue?
>
> No, but I still consider it the same for SOA, because both kinds of
> clients need to be able to identify the recipient of their messages.
Mark, one of the primary issues with your argument is that you suppose that
when
there is some common operational theme to methods within an RPC system that
somehow people would always choose to create a new API so that they would have
enum Bulb {
HarrysBulb, RitasBulb, FranksBulb, GeorgesBulb
};
public interface Access100WattLights {
public void turn100WattBulbOn( Bulb bulb );
public void turn100WattBulbOff( Bulb bulb );
}
public interface Access60WattLights {
public void turn60WattBulbOn( Bulb bulb );
public void turn60WattBulbOn( Bulb bulb );
}
etc. I can only guess that you have some past experience that suggests that
people who write RPC somehow never use an RPC system/platform/capable language
which can provide the same level of abstraction that you think only HTTP can
provide in a RESTful way.
This is where the my arguments are comming from. There's nothing that keeps me
from doing RESTful programming through the RMI programming model. If I do it
with RMI, then I have transparent access to remote services which might be
reached via HTTP, JRMP, IIOP, JERI etc. That is the advantage I have. The
same
programming environment using an arbitrary transport layer for invocation
transport/transfer.
HTTP provides no direct advantage to me. It's not the RESTful semantics of
HTTP
that provide any advantage. I can use a RESTful system without using HTTP! It
is nothing but a transport layer replacement in this context. I don't need the
transfer semantics as a primary part of the system. I might find that when I
use HTTP that I have some particular firewall that I can punch through, or I
might find some other capability to exploit that is a service provided by an
HTTP server. But, it is not HTTP that makes that important. Its what happens
on either end that is the important thing, as Steve has been saying.
Gregg Wonderly
------------------------ Yahoo! Groups Sponsor --------------------~-->
Something is new at Yahoo! Groups. Check out the enhanced email design.
http://us.click.yahoo.com/SISQkA/gOaOAA/yQLSAA/NhFolB/TM
--------------------------------------------------------------------~->
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/
