Patrick,
With respect, the discussion was comparing Jini with Web services, not ESBs. I think it is important for you guys to really try to understand what was intended in Web services. One of the most telling things in Sanjiva's email was the part where he said that if vendors don't improve their tools then Web services will fail. Do not confuse the tools with the specifications. Vendors are doing better but as a general statement they are still thinking too much about the Java and VB objects and how to "derive" Web services from them. This is really backward thinking, like trying to drive in reverse looking in a mirror.
For the record, the IONA ESB does not require our software on both sides - we are happy consuming standard Web services requests from anyone and equally happy sending standard Web services requests. We participated, along with several other vendors, at the recent Microsoft WCF interop "plug fest" and we did not have to install anything on the remote Windows box in order to interoperate successfully with WCF, including extended specifications such as WS-Addressing, WS-ReliableMessaging, and WS-AtomicTransactions. We would have tested WS-Security also but basically ran out of time.
A challenge was posted to the Jini folks on this list a long time ago by John Apps as to how Jini would handle a widely heterogenous IT environment, including IBM mainframes, Tandem systems, DEC minicomputers running VMS, COBOL, PL/I, C++, CORBA, Tuxedo, WebSphere MQ, etc. That has still gone unanswered. As has Sanjiva's latest mention of handling VB-CICS.
Eric
----- Original Message ----
From: patrickdlogan <[EMAIL PROTECTED]>
To: [email protected]
Sent: Monday, April 17, 2006 10:27:51 AM
Subject: [service-orientated-architecture] Re: TSpaces
> Jini suffers... in order to play you needed their software on every
> box... getting it on every box is not easy.
>
> That's the big difference between CORBA, RMI, Jini, E-Speak and
> WS-*/REST. In Web services and REST style services, you don't need
> to go and download some software to participate .. all you need is
> an HTTP server and some code to process the standard messages coming
> on the wire.
This is an apples and oranges comparison. Yes, putting a SOAP port is
can be done using an IDE in just four steps. But Jini is more like an
"enterprise service bus". Simple SOAP can be integrated with either
and EBS or Jini.
Both the ESB and Jini require something to be installed on at least
one computer. Not necessarily the same server(s) as your simple SOAP
clients or servers, though.
The "Jini requires Java" doesn't fly so well either. An ESB-sized
infrastructure will require a significant new investment if one is not
already invested. The target audience is almost certainly invested in
Java to a reasonable degree. Those that aren't, say a pure Microsoft
world, are less likely to invest in any of the ESB-like
infrastructures.
I chalk up the slow start to EJB getting so much (undeserved)
attention for so many years, and to the failure of DCOM giving rise to
SOAP and its subsequent (undeserved) bandwagon.
Notice how there are really two architectures that get discussed on
this SOA forum: REST/HTTP and Jini/Javaspaces. No one talks about
"SOAP architectures" because a generic interface technology is not in
itself an "architecture".
-Patrick
----- Original Message ----
From: patrickdlogan <[EMAIL PROTECTED]>
To: [email protected]
Sent: Monday, April 17, 2006 10:27:51 AM
Subject: [service-orientated-architecture] Re: TSpaces
> Jini suffers... in order to play you needed their software on every
> box... getting it on every box is not easy.
>
> That's the big difference between CORBA, RMI, Jini, E-Speak and
> WS-*/REST. In Web services and REST style services, you don't need
> to go and download some software to participate .. all you need is
> an HTTP server and some code to process the standard messages coming
> on the wire.
This is an apples and oranges comparison. Yes, putting a SOAP port is
can be done using an IDE in just four steps. But Jini is more like an
"enterprise service bus". Simple SOAP can be integrated with either
and EBS or Jini.
Both the ESB and Jini require something to be installed on at least
one computer. Not necessarily the same server(s) as your simple SOAP
clients or servers, though.
The "Jini requires Java" doesn't fly so well either. An ESB-sized
infrastructure will require a significant new investment if one is not
already invested. The target audience is almost certainly invested in
Java to a reasonable degree. Those that aren't, say a pure Microsoft
world, are less likely to invest in any of the ESB-like
infrastructures.
I chalk up the slow start to EJB getting so much (undeserved)
attention for so many years, and to the failure of DCOM giving rise to
SOAP and its subsequent (undeserved) bandwagon.
Notice how there are really two architectures that get discussed on
this SOA forum: REST/HTTP and Jini/Javaspaces. No one talks about
"SOAP architectures" because a generic interface technology is not in
itself an "architecture".
-Patrick
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.
- Re: [service-orientated-architecture] Re: TSpaces Eric Newcomer
- [service-orientated-architecture] Re: TSpaces patrickdlogan
- [service-orientated-architecture] Re: TSpaces patrickdlogan
- Re: [service-orientated-architecture] Re: TSpac... Dan Creswell
- Re: [service-orientated-architecture] Re: TSpaces Dan Creswell
- Re: [service-orientated-architecture] Re: TSpac... Anne Thomas Manes
- Re: [service-orientated-architecture] Re: T... Dan Creswell
- Re: [service-orientated-architecture] R... Anne Thomas Manes
- [service-orientated-architecture] ... patrickdlogan
- [service-orientated-architecture] WS-Po... patrickdlogan
- Re: [service-orientated-architectu... Anne Thomas Manes
