Thanks James,

You are right that my question was not formulated correctly because, may
be, I tried to short the way. The real problem is finding pattern that
allows an obvious, cross-platform solution to synchronous and
asynchronous message passing.

We already have the solution, which is a conjunction of JMS, JMS
Response strategy, Transfer Object, Transfer Object Assembler, and Web
Service Broker Pattern.

As to particular technology, we have a lot of knowledge inside of the
firm. Anyway, your answer confirms our approach.
One more question. Can you suggest other sources (book, i-net) dealing
with this issue, especialy with Web Service Broker pattern and its
strategies.

As to You Mark,
When discuss some issue I expect to concern replay rather than the
uncouth from 'intelligent' persons. Also I think that the word 'whining'
does not an intelligent one. Any way, if you have some problem with me
personaly you can e-mail me directly aharon@(protected).



Aaron Tubman


-----Original Message-----
From: An interest list for Sun Java Center J2EE Pattern Catalog
[mailto:J2EEPATTERNS-INTEREST@(protected)
Sent: Friday, March 05, 2004 3:31 AM
To: J2EEPATTERNS-INTEREST@(protected)
Subject: Re: Moderate this list?

Aaron,

My apologies for singling out your question for criticism. I did not
wish to cause offense, rather to illustrate the tendency of posts in
recent times to stray away from questions that either directly relate to
the book or are focussed on the applications of patterns in enterprise
solutions.

There are a number of comments that are more off-topic than I consider
the interoperation question to be - perhaps I could have chosen better,
or provided other examples? Also, I must agree that transport layers are
an architectural concern. However, IMHO, the specific choice is not; the
ensuing discussion was almost wholly concerned with these specific
technical decisions.

How to create a middleware solution in a manner that does not mandate
the choice of a particular transport layer is a tricky question, and
perhaps one that could be discussed?

To the list: how /would/ you create an cross-platform solution that
abstracts the transport layer? Is it possible to build a solution that
uses CORBA, XML-RPC or SOAP-RPC _but_ keeps transport-specific code out
of the business logic? If I decide to use SOAP-RPC and then decide I'd
rather use CORBA, how can the client application abstract these
concerns?

Note that Java-based J2EE clients don't have this problem; JNDI sort of
does the job here. Other platforms aren't quite so fortunate though.

Regards,
James Telfer

> -----Original Message-----
> From: Aaron Tubman [mailto:aharon@(protected)]
> Sent: Thursday, 4 March 2004 18:50
> To: J2EEPATTERNS-INTEREST@(protected)
> Subject: Re: Moderate this list?
>
>
> First of all I have asking not only about c++-java communication
> technology but about a common approach too. In additional, you cannot

> limit discuss with particular book. The fact is that the solution lies

> in design sphere and not a technological.
>
> Aaron Tubman
>
>
> -----Original Message-----
> From: An interest list for Sun Java Center J2EE Pattern Catalog
> [mailto:J2EEPATTERNS-INTEREST@(protected)
> Sent: Thursday, March 04, 2004 2:59 AM
> To: J2EEPATTERNS-INTEREST@(protected)
> Subject: Re: Moderate this list?
>
> > Mark Galbreath wrote:
> > Why? Are people drinking too much?
> *lol*
>
> > Mark
> >
> > Nick Lothian wrote:
> > >Is it possible to switch on moderation for this list?
> > >
> > >Nick
>
> I think Nick is referring to the large number of posts in recent times

> that have not been even tangentially pattern related. The most
> striking example
> of this is the C++ - Java communication thread. IMHO these sort of
> questions
> are better sent to a different forum: not because those subscribed are
> not
> able to answer them, but because the reason for subscription to this
> list is
> to exchange ideas and information about pattern-based design.
>
> There has been some insightful, pattern-related discussions since I
> subscribed, so I am keen to preserve the usefulness of the list.
>
> My 2c :)
>
> JT
>
> ====================================================================
> Companion Site: http://www.corej2eepatterns.com
> J2EE BluePrints: http://java.sun.com/blueprints/corej2eepatterns
> List Archive:
> http://archives.java.sun.com/archives/j2eepatterns-interest.html
> Unsubscribing: email "signoff J2EEPATTERNS-INTEREST" to
> listserv@(protected)
>
> ====================================================================
> Companion Site: http://www.corej2eepatterns.com
> J2EE BluePrints: http://java.sun.com/blueprints/corej2eepatterns
> List Archive:
http://archives.java.sun.com/archives/j2eepatterns-interest.html
Unsubscribing: email "signoff J2EEPATTERNS-INTEREST" to
listserv@(protected)

====================================================================
Companion Site: http://www.corej2eepatterns.com
J2EE BluePrints: http://java.sun.com/blueprints/corej2eepatterns
List Archive:
http://archives.java.sun.com/archives/j2eepatterns-interest.html
Unsubscribing: email "signoff J2EEPATTERNS-INTEREST" to
listserv@(protected)

====================================================================
Companion Site: http://www.corej2eepatterns.com
J2EE BluePrints: http://java.sun.com/blueprints/corej2eepatterns
List Archive: http://archives.java.sun.com/archives/j2eepatterns-interest.html
Unsubscribing: email "signoff J2EEPATTERNS-INTEREST" to listserv@(protected)