 | 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 Sean Brydon
Back
Hi,
Just some brief thoughts.
-It sounds like your applications need a Factory to look up the
particluar service they require. This is similiar to a DAO Factory that
looks up the DAO it needs for a partcilaur datasource type.
-You could put the version to use info in the deployment descriptor as
an env-entry
An example of this can be seem at the BluePrints adventure builder app at
http://java.sun.com/blueprints/code/adventure/1.0/src/com/sun/j2ee/blueprints
/util/dao/DAOFactory.java.html
-I would recommend leaving the ServiceLocator focussed on looking up
J2EE resource factories such as EJB Homes, etc. It has a specific
purpose and you may want to keep it focussed instead of adding exytra
functionality to it. Instead use a factory to return an instance of the
service your app requires.
hope that helps,
Sean
Eugene Ostroukhov wrote:
>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)
>
>
====================================================================
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)
|
|
|
