Return-Path: Delivered-To: apmail-incubator-geronimo-dev-archive@incubator.apache.org Received: (qmail 4264 invoked by uid 500); 26 Aug 2003 03:55:09 -0000 Mailing-List: contact geronimo-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: geronimo-dev@incubator.apache.org Delivered-To: mailing list geronimo-dev@incubator.apache.org Received: (qmail 4186 invoked from network); 26 Aug 2003 03:55:07 -0000 Received: from unknown (HELO main.gmane.org) (80.91.224.249) by daedalus.apache.org with SMTP; 26 Aug 2003 03:55:07 -0000 Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 19rUw6-0003dn-00 for ; Tue, 26 Aug 2003 05:56:02 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: geronimo-dev@incubator.apache.org Received: from sea.gmane.org ([80.91.224.252]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 19rUw5-0003df-00 for ; Tue, 26 Aug 2003 05:56:01 +0200 Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian)) id 19rUvH-0006GX-00 for ; Tue, 26 Aug 2003 05:55:11 +0200 From: Richard Monson-Haefel Subject: Re: Axioms for JCA implementation Date: Mon, 25 Aug 2003 22:53:23 -0700 Lines: 89 Message-ID: References: <7BB5E7895129484FB9705F711466DEFD0161B243@snnexc03.in.ce.com.au> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="B_3144696804_393128" X-Complaints-To: usenet@sea.gmane.org User-Agent: Microsoft-Entourage/10.1.0.2006 Sender: news X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3144696804_393128 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit On 8/25/03 3:51 PM, in article BAY8-DAV16HtMFaukyC00043d86@hotmail.com, "kamesh kompella" wrote: > Hi Richard, > Thanks for the info. In that case, I will look into getting > RA going for openjms. This will be the "dummy" RA that can be used for testing > the app server's contract's implementation once the infrastructure is in > place. > > I was intrigued by one of your statements: > "Personally, I don�t think the CCI offers much value. Most Ras will have very > specific APIs. I think we should avoid supporting it." > Is the variability in API ok as the code will be derived at deployment time > with the help of some tools which will hide the custom API from source code? > Also, what happens to two tier clients ( Should we leave them out altogether > since this is as bad as mixing DB calls in a JSP) ? Do we assume that these > clients will talk to the App server? > > Thanks. > Kamesh If I remember correctly � its been a couple of years � the CCI is an abstraction for a synch resource. The idea was to create an API that any resource could implement, regardless of its purpose. However, in practice each type of resource has its own API and usually its easier to work with that, than a generic abstraction. I think some vendors have implemented the CCI for ERP RA adapters, but I�m not sure about that. Personally, I don�t think the CCI adds much value, but I don�t really care if someone else wants to implement it. Richard --B_3144696804_393128 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: Axioms for JCA implementation On 8/25/03 3:51 PM, in article BAY8-DAV16HtMFaukyC0004= 3d86@hotmail.com, "kamesh kompella" <kompella_geronimo=3DPkbjNfxx= IARBDgjK7y7TUQ@public.gmane.org> wrote:

Hi Richard,
            &nb= sp;     Thanks for the info. In that case, I will l= ook into getting RA going for openjms. This will be the "dummy" RA= that can be used for testing the app server's contract's implementation onc= e the infrastructure is in place.  
I was intrigued by one of your statements:
"Personally, I don=92t think the CCI offers much value. Most Ras will ha= ve very specific APIs. I think we should avoid supporting it."
Is the variability in API o= k as the code will be derived at deployment time with the help of some tools= which will hide the custom API from source code? Also, what happens to two = tier clients ( Should we leave them out altogether since this is as bad as m= ixing DB calls in a JSP) ? Do we assume that these clients will talk to the = App server?

Thanks.
Kamesh

If I remember correctly – its been a couple of years — the CCI = is an abstraction for a synch resource. The idea was to create an API that a= ny resource could implement, regardless of its purpose. However, in practice= each type of resource has its own API and usually its easier to work with t= hat, than a generic abstraction.  I think some vendors have implemented= the CCI for ERP RA adapters, but I’m not sure about that. Personally,= I don’t think the CCI adds much value, but I don’t really care = if someone else wants to implement it.

Richard --B_3144696804_393128--