On 5/29/06, Gregg Wonderly <[EMAIL PROTECTED]> wrote:
> 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.
Well, I think most would argue that in the end, but deciding what is
unnecessary or not is a big issue in itself, one that doesn't have a
true or false answer; Surely you're talking about specific ones, such
as XML (text) transformed from one object code into another? So if
you're in a Java-only environment, if the framework can avoid
ojbect-text-object transformation by embedding end-object models
directly in the protocol, then it should do that; in other words,
being protocol-agnostic? I can give you examples where the object
model to text to object model transformation is sometimes faster /
sometimes preferred than complex object to object model
transformations, for example where POJO to DOM object conversion is
slower than POJO to XML to DOM; this is of course because once people
start modelling in tree-structures as opposed to object models they
possibly alter their thinking on their POJO objects to begin with
(sorry to be harping on these things; I find them very interesting and
important). It all depends.
> 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.
Hmm, we are mainly a Java shop (well, not entirely true; we're a mixed
bag, with 70% Java), but I've noticed that playing the all-embracing
Java / Jini game stops innovation in its track. And it's not from Jini
nor Java being *able* to do SOA across a number of protocols, but
because of that very agnosism to protocol that that layer isn't
addressing. And in so doing, oppertunities gets lost because lazy
developers leave it all to the framework.
Hmm, it's more lazy developers and programmer mentalities I fear with
RMI / Jini, not so much the amazingness of the technology itself; I
fear that trusting the framework stops them worrying about things that
perhaps they don't really have to worry about but maybe should. Yes, a
bit vague. Sorry, I've dealt with too much lazy development of late
that has resulted in things not being done properly; if developers
*can* avoid doing something, they will, and *my* theory is that this
leads to sloppy infrastructure. Should developers use Jini in certain
instances? For sure, but make sure they understand what Jini is doing.
> 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.
I'm going to bite on this bait; why not? :)
> > 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).
Ok, I think I understand what you're saying here. Personally I would
not like to think that such decissions had to be made at deployment
time; I'd chalk that up to poor design to begin with, although of
course I've had these things happen to me where I wished I could use a
different channel because the current one sucks. However, we're not a
high transaction shop, and as such I'd prefer to keep things even
simpler and let Moore's Law fix most of our performance problems. :) I
know that this is heretic preaching to many, but for us it is more
important to keep things as simple as possible (we are desperate to be
able to innovate and create creative new ideas quickly; performance is
second or third down the list). This is *why* RESTful SOA fits so well
with us because everyone can handle a bit of XML and a few
instructions on some kind of URL API, but it gets hairy as soon as you
introduce the WS-* stack or demand that all services can issue
bytecode on the JVM to the services Proxy. :)
> The issue is that if you take enough liberties with your implementation details,
How does Jini / protocol-neutral systems do this part better? Or are
you now just referring to the protocol layer implementations?
> 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.
Ok, I'm looking. This is a universal problem, not one specific to just
protocol-wars. :)
> Look at my recent question about the latest EBay REST API.
Where is your question?
> 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.
Such as?
> You should look at Jini (the Java mobile code enhancements in particular).
Would you recomend that to a place that's not *just* got Java, but
also a swag of stuff like C/C++, Ruby, Perl, LISP, PHP and various 4th
generation languages?
Apart from that, the Jini model does sound like a comfortable
invocation model, and perhaps it is time to at least look at parts of
our infrastructure to utilise it.
> 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.
I've got RMI based systems that totally ignores the rest of the
infranet, so for me, stepping away from a pure Java solution sounds
good to me; we're a diverse shop, and hence it is actually more
important with a standardisation at the top rather than the bottom.
Your rmilage does differ. :)
Kind regards,
Alex
--
"Ultimately, all things are known because you want to believe you know."
- Frank Herbert
__ http://shelter.nu/ __________________________________________________
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.
