Apps, John wrote:
> However, I'd still like to see a couple of usage scenarios using
> Java/Jini to build composite applications consisting of both new and 3GL
> code. I suspect these can and will be built using a variety of
> technologies, including Web Services.
>
> Personally, I think we should be looking at these things from a more
> practical level, size not being relevant, technologies not that relevant
> either, service and ease of development and maintenance being the
> important parts.
>
> No point having the best set of technologies in the world if 1) they
> take years to understand, 2) are in some way proprietary and 3) do not
> allow the integration of existing code.
Look at how long it has taken for people to start to understand distributed
systems and the fact that things will fail. Software will fail, hardware will
fail, the network will fail, people will fail. If you aren't interested in
building fault tolerant software, then probably you won't begin to understand
how technologies such as Jini might help you do that.
Proprietary is an interesting term to through into the mix. The specifications
for Java and Jini are publically available. You can license Java technologies
for your own implementation. If not, then you can freely use the existing
implementations, buy support packages and otherwise have exactly the same
senario that you'd have with most other commercially supported software
environments that might be part of your SOA. Jini is now open source. It's
interface to the world is the JERI stack. On the code side of that, you have
direct access to its powers through Java APIs. On the network side, you have
the ability to plug in whatever transport you want which can meet the contracts
associated with your software's use of the Java APIs. JERI is full of service
provider interfaces, much as Java's security implementation is, which allow you
to completely customize till you have exactly the implementation you need.
If you don't have the technical prowess or resources to effect the
implementation you need, you'll have to look for something that "comes close",
and then wrangle with it. This is exact what most small businesses with
limited
resources already do.
"Integration of existing code" is a buzz phrase. Integration can happen at a
wide range of levels within your SOA. That is why it's important to decide
whether you need an ESB with a standard backbone to use for neutralizing
vendor/proprietary technologies into something that can provide standard
interfaces to standards based systems. Java has great support for a wide range
of standards, and not so great support for others. This is where you have to
balance your investment.
I personally have no problem spending a day to create an neutralization layer
for a particular vendor, or legacy system so that I don't have to compromize
standards, integrity or flexibility of my SOA.
The ESB business is not always the solution, sometimes you don't need that.
But, in the end, no matter what you call it, the "standard" that you decide on
for inter-service communications is your ESB. It might be SOAP over HTTP, it
might be websphere, it might be something else, like TCP-modbus, or something
completely different like MPEG-4.
The choice you make there, will completely control the choices that you get to
make later. By chosing to make transport protocol a neutralization strategy
instead of a backbone choice, you allow yourself to make the most out of your
SOA by providing choices.
Adding Mobile code, as I've said over and over, is another enabler of choice.
There's another good example of where mobile code helps. Let say that you have
a service that performs call backs to the client for notifications. The
Listener model in java is a prevalent design paradigm that provides IOC
features. This paradigm is attractive for a number of reasons. However,
people
have mentioned here repeatedly that fine grained remote calls don't work well
under any kind of significant load.
If you designed an application to use this paradigm, but then wanted to provide
one of the components remotely, you might be tempted to change this paradigm to
use some kind of bulk or batching mechanism. With mobile code, you can do this
transparently to the client. It might get a remote interface that as an
"addFooListener( FooListener lis)" method. With a smart proxy implementation,
the addFooListener() call might just cause a reference to the listener to be
stored in the smart proxy, and then a thread started reading from a socket
created back to the server. As objects arrive, they can be passed back to the
listener by this thread. The client application doesn't have to know about
this
type of optimization.
The recent enhancements to JavaSpaces have provided such optimization
capabilities in an API that allows for batching. There have been reports of
rather large improvments in throughput for applications that previously had to
deal with performance aspects of one object per remote-call.
I've used smart proxies to provide listener implementations for about 4 years
now in my broker. I had a load problem on the server related to all these
inbound calls. One day, I put in the smart proxy, and restarted the broker.
My
customers called about the broker restart, but never knew a thing about the
introduction of the smart proxy. It just worked, and suddenly they saw better
performance because the load on the server was reduced.
Gregg Wonderly
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/
