Todd Biske wrote:
> This is actually a very interesting question. I think Anne hits all
> the technical points right on the nose (as she always does). There
> are some elements that Anne points out that do differentiate a well-
> defined interface in the Web Services world from a typical Java or C#
> class or interface definition. The bulk of it is centered around the
> non-functional aspects and interoperability goals of a Web Services
> based SOA. If we're dealing with local invocation of objects, the
> transport, message formats, etc. are all defined by the underlying
> platform.
Using Jini's JERI package, with Java, allows the transport to be defined
arbirarily at deployment time. That's an important aspect of JERI that keeps
it
from being platform anchored. You can use WS, JRMP, JERI, MODBUS, MPEG4 or
whatever interface you need to the realworld. It doesn't have to be Java
centric.
Jini provides the ability to create really performant SOAs with tools that
already provide 2PC, security, async transport (using Javaspaces and related
services) and other technologies that WS standards orgs and vendors are still
working on. And, I repeat, this is without excluding WS as part of your
worldly
interface set.
> Some non-functional aspects can be externalized, such as
> Security, in the same way that WS-Security and WS-SecurityPolicy
> externalize it within a Web Services model.
Security, in Jini, is covered by the Java security model. The DynamicPolicy
class, introduced in the Jini 2.0 APIs, allows you to create your own policy
implementation that sources policy from whereever you need it from. I use this
feature to make it possible for a client to grant access to services
dynamically. An additional result is that you can place policy implementation
into an exporter implementation so that your policy is independent of the
service vendor.
> If you move to a remote invocations, as long as you stay within a
> platform-specific model, such as .NET Enterprise Services or Java
> RMI, things like transport bindings may still be defined or implied
> by the platform.
It's important to understand that Java has a plugable transport model in the
Jini system. It's not required to use a Java centric transport, at all. It is
a powerful choice, to be able to use mobile code, but its not the only choice
you can make when using Java/Jini. If you are not using Java, then the mobile
code choices you have are limited in most cases to remedial capabilities with
limited security control over the downloaded code (all or nothing in many
cases).
The JERI stack, provides a much more secure model. Here's some points to make
sure you grasp with JERI.
The following are plugable, and provide the ability to substitute or amend
implementations.
1. endpoints - The software entitity that provides the external interface
point for the service. This would be a socket, a serial port, a USB
device, a disconnectable path such as a file stored on a memory stick
etc. With interesting endpoints, you can implement services which might
think that they are talking in realtime to a client which performs
operations at a rate of one per month.
2. Invocation layer - This is the point where transport is interfaced with
encoding and transport of parameters and returned values. This is where
web services can be interfaced to a Jini service without the service
needing to know that it is talking to a web service. WSDL could be used
to generate an invocation layer implementation for example. Constraints
on the transport and security systems utilized are typically asserted at
this layer, but might be commonly known by the endpoint implementation
as well.
3. exporter - Combines the endpoint implementation and the invocation
layer typically, into a software entity which provides the mechanism
for making an object passed to it capable of being interacted with
remotely, using the endpoint and invocation layer. This is the point
where a service can be interfaced to multiple external protocols.
> CORBA moves into a more heterogeneous model, with
> CORBA IDL being more analogous to WSDL, but I think each new
> description language has tackled the problem better than the
> predecessors.
The question for me is whether it makes since to abstract this description with
a manually created "description" which mirrors a machine readable interface
defined by your implementation language.
> A very easy example to comprehend is the notion of side
> effects. If I have a "deposit" operation in my bank account
> interface, I expect that it will increase my balance by the amount I
> deposit. If, however, it takes out $2.00 for a processing fee and
> I'm not aware of that, it's a poorly defined interface.
/**
* This interface defines the ability to make a deposit into a
* particular Depositor. It requires the use of the Currency
* type to specify the source of the funds to deposit as well
* as the source of any acceptable fee.
*/
public interface Depositor extends Remote {
/**
* Make a deposit with indication of acceptible fee.
* @param amount the amount to be deposited
* @param fee the amount of fee willing to pay to make deposit
* @throw DepositFeeInsufficentException if the provided fee
* value is insufficient based on this Depositor's agreements
* or support for the indicated Currency source.
* @throw IOException if an error occurs accessing the Depositor or
* any resources related to the Depositor providing this service.
*
public double deposit( Currency amount, Currency fee )
throws DepositFeeInsufficentException, IOException;
}
There are probably some other things to talk about. This interface allows the
users interface, GUI or otherwise, to get explicit information about the type
of
failure which might require the user to provide additional control. On the
other hand, if you have an arrangement that is well known, for fee costs, you
can provide that fee, and not have to handle the exception as a user
interaction, but rather as a notification that your agreement is no longer in
place, or something else is amiss.
Interesting example, but not hard to come up with a solution for.
> I'm interested in what others have to say. Now I'll go back and try
> to help my wife figure out which button in the minivan is the rear
> defroster versus the front defroster. One button has a rectangular
> window with wavy lines in it, one button has an arced window with
> wavy lines in it. Completely intuitive, right?
This is a really amazingly silly thing for me too. Perhaps it's good that she
doesn't have rearview mirror defrosters too!
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/
