> On 5/28/06, Gregg Wonderly <[EMAIL PROTECTED]> wrote:
> > The issue is whether that optimization is an integral part of your architecture
> > such that it can't be removed or changed with deployment kinds of configuration
> > management. When there is little chance of configuration, there is little
> > chance of evolution.
>
> True, but what makes one better than the other in this respect? The
> WS-* stack doesn't come with more flexibility in this regard. As far
> as I can tell, you don't like the lack of fixed / standardised XML
> schemas for transportation of information?
Okay, I'm not arguing in favor of SOAP at all. I'm arguing against unnecessary
data transformations. I'm in the "RMI works fine for Java applications" camp.
And as I've said before if you are using Java, you really should use Jini for
your distributed computing activities where you are doing Java-to-Java things.
When you have to use SOAP, use it. If you have to talk to a REST beast, talk
REST. But, don't dumb down the posibilities of the Java mobile code model just
because everyone says SOAP or REST or RSS or ... is really cool.
> > > But yes, SOAP vs. REST should be void of wire discussions, up until a point
> > > where even wire means something to an enterprise architect. Again, it
> > > depends on how big a bang you're designing.
> >
> > The decision should be based on deployment needs, not so much software
> > architecture. Software architectures and platforms can enable such flexibilities!
>
> Hmm, but deployment needs can also change. I'm not sure there is a
> fixed answer to this one.
Right, so you should be able, at deployment time, to choose a different
transport/transfer/invocation technology and your application be none the wiser.
With Java, if your application architecture is "just java", or POJO as some
people like to say, then you have every opportunity, at deployment time, to
transliterate between different transports and invocation models, because you
can choose the correct level of abstraction at deployment. If you choose an
abstraction in your application, which doesn't scale/fit/work at some point,
then you'll be left to rearchitect, instead of just tune the deployment. The
java mobile code model amplifies deployment opportunities, because you can move
computational and network features of your "service" between the client and
server(s) environment(s).
> > Specifically, I'm refering to the inability of the developer to allow the
> > deployer to make "arbitrary" choice of transport, because of arctecture or tools
> > available to them/used by them.
>
> So, by deployer you mean someone who installs and maintains the
> "network" (or SOA) as opposed to the individual application developer?
> Doesn't this depend on how big an enterprise you've got, how it's
> structured and who's running it? For example, I'm a developer and
> deployer of many things in my organisation. If there are rules (or
> architectural descissions made to be followed) imposed from other
> parts of the organisation, sure there will be something you can and
> can't do. Just don't know if REST vs. WS-* *can* have a clear winner
> is this respect.
For me, you don't choose REST or WS-* to "win". You choose it because you have
to give into the limits of another system that you have to interface with.
> > The problem with REST is that it really allows the content to be very
> > unstructured in both directions.
>
> Depends on how you set it up. It's easy enough to use XML technologies
> to ensure highly structured data. SOAP is just a *given* standard to
> do this that people can follow, but you don't have to play SOAP/WS-*
> to have high structure. For example, in our SOA we use a Topic Maps
> based schema that all services a guaranteed to deliver; input is
> optional REST or the same schema, or some times even SOAP (without the
> transaction bits).
The issue is that if you take enough liberties with your implementation details,
and allow enough wide interpretations, then you end up with contracts between
clients an servers which are not strictly visible in the documented API. This
"flexibility" makes it difficult to manage large scale deployments.
Look at the places that REST is making headway. It's in the places where there
will be millions of clients, not in the places where there are 10's or 100's of
clients. That means that anytime something has to change, the impact is huge.
Look at my recent question about the latest EBay REST API.
> > So much so that once you have REST in place,
> > you probably can never change the client nor the server to a different
> > transport/platform interface.
>
> Why not? And how does SOAP/WS-* differ?
It doesn't differ, when used in a RESTful way. It has the same problem. The
dependency on the HTTP protocol as an application protocol means that there are
certain semantics and certain features which your application ends up depending
on. Some of those things are not visible in other protocols that might be more
useful under certain circumstances. That's why I argue that depending on HTTP
as a transfer protocol has perils.
> > Some think that this is the power of REST. I
> > consider it to be THE problem with REST. With a strict interface description
> > and implementation, you have the ability to loosen the details to fit the needs
> > of future clients. With a loose interface description and implementation, you
> > have no ability to tighten it later to provide a better QOS or other needed
> > functionality.
>
> Hmm. With SOAP, I need a library to handle the SOAP way of dealing
> with things, but with most REST I can just pass it in to my XSLT
> processor for some light-hearted handling (maybe my XSLT preference
> also plays into this as well). In fact, I mostly get tired of all the
> helper-classes I need to implement and possible frameworks to do just
> basic stuff, and this *does* get in the way of rapid prototyping and
> innovation.
You should look at Jini (the Java mobile code enhancements in particular).
There are no helper-classes, mapping or transformation required in APIs or their
use. You can send stuff through a method based invocation model as your client
API. If you do need mapping/transformation or other interworking support code,
you can do that at deployment time by plugging into the JERI stack with an
appropriate solution.
If you aren't doing Java, then you'll have to look at your programming language
to see what it is that you have available. A SmartProxy allows me to send code
to the client that executes there. It's a serialized object which can carry
zero or more remote proxies that provide access to the actual services that the
clients interface needs access to. I can cache, lazy write, do load
distribution, do automatic failover, etc, in the smart proxy. The client
software never needs to know that such services exist, or their implementation
details.
Instead, I am free to change all those details, on the fly, over time, and keep
the clients happy with a single API interface, but with different
implementations that provide them with exactly the features they need.
That's what's missing from non-mobile code environments such as WS-*, REST etc.
That's because they are choosing to standardize an interworking language in
terms of the transport/transfer protocols, instead of standardizing at a much,
much higher level, the service API.
Gregg Wonderly
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.
