Christof Ameye wrote:
>Hi Ken,
>
>Ok very nice, but what about Java EE applications that connect to
>several other application servers from within the same single application,
>or even on complexity more: the server they connect to must be run-time
>configurable in the application itself ?
>
Hi Christof,
You're right that some of these use cases are not covered by the spec.
In general, the
spec deals with a component accessing a Java EE implementation for a
single vendor
at a time.
For EJBs, there is a portable way to access Remote Home objects from
multiple vendors
using the corba interoperable naming syntax. You define an ejb-ref
and/or @EJB
and code to it in the normal way. However, in the vendor-specific
mapping file
(e..g sun-application-client.xml) the ejb-ref is resolved using a corba
interoperable
name such as corbaname:iiop:<host>:<port>#<target_global_jndi_name>.
This allows
location transparency without the need to change any portable application
code or deployment descriptors.
--ken
>
>Christof
>
>Kenneth Saks wrote:
>
>
>>Christof Ameye wrote:
>>
>>
>>>Anyway,
>>>
>>>If you have a strongly distributed architecture with several application
>>>servers you already have to use the properties mechanism to be able to
>>>distinguish the different application servers.
>>>
>>>
>>Hi Christof,
>>
>>That is not true. A valid Application Client container implementation
>>must allow
>>the client naming provider to be configured without relying on
>>application code.
>>Otherwise, there is no portability. Our appclient command allows
>>these to be
>>set via an optional Application Client .xml file. In our case, they
>>default to
>>localhost/3700.
>>
>>All of the Java EE compatibility tests that
>>have client functionality are developed as Java EE Application
>>Clients. These
>>components use either Java EE 5 annotations or no-arg new
>>InitialContext() +
>>lookup() relative to java:comp/env to retrieve their resources. Each
>>vendor runs these same Application Client components with their
>>application
>>server. They don't have the option of recompiling the client code to
>>pass
>>different properties to InitialContext.
>>
>>Anytime you see a java client that uses something other than the no-arg
>>InitialContext() to access Java EE resources/ejbs it is by definition
>>non-portable.
>>That's one of the differences between what we refer to as a
>>stand-alone java
>>client and a Java EE Application Client component.
>>
>> --ken
>>
>>
>>
>>> The same applies if you
>>>connect to one application server from within another one.
>>>I don't think Java EE 5 solves that problem. Or maybe we could solve
>>>this by playing with the class loader (but does that simplify things,
>>>rather not).
>>>
>>>Christof
>>>
>>>
>>>Takashi Nishigaya wrote:
>>>
>>>
>>>
>>>>Thanks, Ian.
>>>>
>>>>Yes, Java Web Start may be a good choice for portability.
>>>>I will evaluate it.
>>>>
>>>>Thanks,
>>>>Takashi Nishigaya
>>>>
>>>>Ian Evans wrote:
>>>>
>>>>
>>>>
>>>>>Takashi Nishigaya <Takashi.Nishigaya_at_Sun.COM> wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>Thank you for your valuable sugestions.
>>>>>>Yes, @EJB is really good feature in Java EE 5.
>>>>>>Maybe it is time to use the client container.
>>>>>>
>>>>>>But for portability issue, different vendor provides the different
>>>>>>command usage for client container. It raises another issue about
>>>>>>packaging of the portable ejb client application, i.e.,
>>>>>>
>>>>>>which is protable? properties + classpath vs. wrapping command line
>>>>>>
>>>>>>
>>>>>>
>>>>>Glassfish/App Server 9 uses Java Web Start to simplify packaging and
>>>>>running Java EE App Clients. It's the best solution for running
>>>>>remote app clients.
>>>>>
>>>>>http://blogs.sun.com/roller/page/quinn?entry=how_does_glassfish_know_about
>>>>>
>>>>>http://docs.sun.com/app/docs/doc/819-3659/6n5s6m5aa?a=view
>>>>>
>>>>>I don't think we've done enough to promote app client use generally
>>>>>or to publicize our Java Web Start-able app client feature.
>>>>>
>>>>>-ian
>>>>>
>>>>>
>>>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: ejb-unsubscribe_at_glassfish.dev.java.net
>>>For additional commands, e-mail: ejb-help_at_glassfish.dev.java.net
>>>
>>>
>>>
>>>
>>
>>
>
>
>
>