 | Mailing List | | Home | | Forum Home | | JBoss - Java Application Server | | Struts - A MVC web framework | | Tomcat - JSP/Servlet container | | iText - An open source PDF Java Library | | JDOM - JDOM XML Parser | | J2EE - A mailing list for Java(tm) 2 Platform, Enterprise Edition | | J2EE Pattern - An interest list for Sun Java Center J2EE Pattern Catalog | | Servlet - A mailing list for discussion about Sun Microsystem's Java Servlet API Technology | | JSP - A mailing list about Java Server Pages specification and reference | |
Struts & Hibernate
|
|
|
| | | Service Locator for versioned services | Service Locator for versioned services 2003-08-14 - By Eugene Ostroukhov
Back
ejb-ref element in the XML descriptor of the web-app or EJB-jar should solve
the issue, I guess.
Eugene
-- -- Original Message -- --
From: "Moore, Gary" <gmoore@(protected)>
To: <J2EEPATTERNS-INTEREST@(protected)>
Sent: Thursday, August 14, 2003 4:38 PM
Subject: Re: [J2EEPAT-INT] Service Locator for versioned services
> Ian,
>
> Very interesting thoughts for this.
>
> I think it would be more work and would complicate your
> ServiceLocator beyond what is needed.
>
> The problem you speak of to me seems more like a deployment time
> consideration. Thus, may be best handled via the application assembler
role.
> The application assembler should determine which version of the services
to
> use as part of the application functionality and create the application
> archive (.ear) containing those correct service jars. If your services
are
> backed by EJBs, I have never tried to deploy multiple applications with
the
> same, or different EJB versions, possibly bound to the same physical JNDI
> name. It would be curious to see how well container providers support this
> scenario, could they even deploy 2 or more instances of the same EJB.
>
> Unless you intend to have the capability in code to switch between
> versions of EJB interfaces. In this case, you would still need some kind
of
> Factory pattern to determine the correct version of the service to use
> anyway (to keep the client code neutral). So it would seem better to put
the
> requirement of determining the correct version to the Factory and it can
> still gain the benefits of the ServiceLocator pattern for caching and
> simplifying the lookup of the services.
>
> Just my $0.02,
> Gary
>
> -- --Original Message-- --
> From: Ian Vellosa [mailto:vellosa@(protected)]
> Sent: Thursday, August 14, 2003 3:02 AM
> To: J2EEPATTERNS-INTEREST@(protected)
> Subject: Service Locator for versioned services
>
>
> Good morning people.
>
> I'm hoping that some of you can help stimulate ideas in my mind with
regards
> the Service Locator.
>
> After writing an initial application which was all contained in one large
> ear, we have recently embarked on a process of splitting up the
application
> into a number of services each of which have their own ear. Now that the
> next application is in development and modifications need to be made to
the
> base services we would like to deploy different versions of the same
> service. So we deploy two ear files.
>
> service-1 (See http://ice-1.ora-code.com).0.ear
> service-2 (See http://ice-2.ora-code.com).0.ear
>
> and within them we have JNDI names something like
>
> /CompanyName/ServiceName/VersionNumber/ejb
>
> I would like to include a properties/xml file as part of the deployment
for
> my application that says it should use version 1.0 of service X and
version
> 1.3 of service Y etc and have the Service Locator use this file to look up
> the correct version of the EJBs.
>
> Have people done or thought about this before?
>
> Are there any resources about that can help me? (I can not find anything
on
> the Sun Java site)
>
> Does anyone have any words of wisdom for me?
>
> Any help is most appreciated
>
> Thanks in advance
> IV
>
> ====================================================================
> 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)
|
|
|
