Re: [service-orientated-architecture] SOA Pizza Order Surprises
- View SourceOn 2/23/07, Eric Newcomer <e_newcomer@...> wrote:
>It's not just you. In my estimation, the uniform interface is the
> It seems like on this thread, whatever the question, the answer is "uniform interface."
> Maybe it' just me.
greatest advance in the history of large scale distributed computing
... well, in conjunction with standardized identifiers I suppose. So
it's really no surprise that it's the answer to many questions. 8-)
But FWIW, the uniform interface isn't the only way to get
self-descriptive messages. If the interface is standardized then it
is self-descriptive. That's why SOA/WS (and ONC, DCE, CORBA, DCOM,
RMI et al) - which unapologetically do *not* constrain the interface -
never had, and will never have, self-descriptive messages in the
general case. It's the main reason we don't see those systems on the
*ALL* Internet based systems have standardized operations. This is
not a coincidence.
Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca
Coactus; Web-inspired integration strategies http://www.coactus.com
- View SourceJan Algermissen wrote:
> In RMI, I belive the client has very detailed expectations beyondThe HTTP operations, GET, PUT and DELETE do have more exact descriptions than
> 'invoke' and it would lead to
> many surprises if INVOKE( foo.getStockQuote) launches a missile, or?
> In fact, when you POST your order to e.g. Amazon, it would be perfectly
> fine (from an HTTP POV)
> for the server to launch that missile.
POST. This is just an simplification of the interface that an HTTP client would
deal with. It indicates a more focused application group that HTTP can be used
from. POST represents the generic "punt" that creeps into software when
developers decide that they can't provide some needed functionality in an
existing implementation. It's a very pervasive thing.
The RMI INVOKE operation, as I said, is what allows the Java programmer to
access remote objects with the same programming paradigms as they do local
I'm not sure that the 'launch a missle' example really applies here. Unless you
wrote the software on the other end, you don't really know what happened. Even
with GET, PUT and DELETE there's no guarantee about anything, we just have, as
the greater software development society, largely been truthful, trustworthy and
faithful, recognizing the benefits of that premise.
> That is (and this is how this thread started, BTW) why it is soThe Java progamming language provides as much self description in the
> important that what the client says
> is self describing. - It keeps you from being responsible for that launch.
specification of an API design as any other textual representation of similar
information. Developers describe their intent with software in whatever
language they use. Currently, we don't have a silver bullet language that can
provide any real guarantees about what happens remotely.
However, the JERI stack, does include the ability for the client to assert
contstraints that the server must meet. Those constraints are validated by the
ProxyPreparer. The ProxyPreparer can be told to perform proxy verification.
The existing implementation of this knows how to validate that the proxy
verification is happening with the appointed classes from the desired class
loader. Once the validation occurs, then the client can assume that the proxy
preparation included validation of the specified constraints which includes
thigns like server authentication (Kerberos or X.500 types of things), proper
integrity of the downloaded classes (httpmd: protocol handler), proper integrity
of the data path (SSL vs TCP endpoint) etc.
HTTP and web clients don't really allow users to specify this kind of fine
grained control in the typical installation. Instead, we rely on the browser to
tell us when a form is being submitted on a non-https connection etc.
I think that there's a much bigger picture than just the HTTP protocol.