Gervas Douglas wrote:
> One of the topics that came up in the conversation was tuple spaces as
> middleware in a SOA context, and more specifically the idea of using
> XML tuples, which unlike JavaSpaces would enable a
> language-independent tuple spaces product. Have any of you heward of
> such a solution for a decoupled SOA middleware requirement?
Its amazing how Anne continues to associate language dependence and Java/Jini.
I don't know how else to explain the JERI stack to make it clear that JERI is
the demarcation of Java/Jini to XXXX conversion. Instead of my services having
to codify its behaviors and data into WS-*/SOAP/REST/whateveritistoday, my
service is written simply and neatly as a Java application that uses the RMI
programming model for all service interactions.
All I have to do is create an (or more typically just use an existing) endpoint
that talks the wire protocol needed, and then create an invocation layer
Handler
for the invocation layer and I can talk any protocol and data format you need.
All the things that you do to your service to make it
WS-*/SOAP/REST/whateveritistoday, I do to my invocation layer handler. But I
have a level of abstraction that is configuration/deployment time decided
rather
than developed into the application.
I don't have to recreate Javaspaces, distributed transactions, distributed
leasing or security implementations. It's already in place. I just add the
specific details I need for a deployment and I'm done.
What am I missing in Anne's argument?
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/
