Interface to Client Tier

Thank u Scott Orshan
We use the "dispatcher" service because we wanted to supply a general interface
to the Client Tier. Do you have some better suggestion?
Is it nessary?
or, We use a control class to tp_call the service?
Scott Orshan <[email protected]> wrote:
While it is more efficient to call the services directly, I have seen
many
applications implemented with such a "dispatcher" service.
Your Entry service is not necessary for Tuxedo, but only you know if
it is
necessary for your application.
Scott Orshan
zhangjr wrote:
Hi:
I want some suggestion about how to deploy services in processes.
we design a Entry Services, all client call the Entry Services, and the Entry
Service dispatch requestion to appropriate 'real' services. is it correct design?
thx

Peter,
Thank your reply.
At our All client GUI(C++ Builder), we use an 'ID' Field in FML to identify the
'real' services ,
set all information /data inputted from the GUI to the FML,
and then we call a general service,eg, service_dispather.
I think it's not a good design.
Peter Holditch <[email protected]> wrote:
zhangjr,
I am interested to know what you are looking for as a "general interface
to the client tier" Can you give more detail as to ehat you're trying
to build?
From my point of view, if you choose a consistent set of FML field
definitions and a set of meaningful service names for your application,
then you have a general interface between the client and the server
the client populates relavent fields into a buffer and invokes the
required service (via tpcall) before processing its reply. The only
coupling between client and server is the shared understanding of the
buffers that pass between them - a good coarse grained, loosely coupled
interface.
It sometimes amuses me to note that this is how Tuxedo has worked since
thye late 1980s. It is now being touted as the next great thing in
software architecture under the name of "Service Oriented Architecture"
in the context of Web Services... Plus ca change :-)
Regards,
Peter.
zhangjr wrote:
Thank u Scott Orshan
We use the "dispatcher" service because we wanted to supply a generalinterface
to the Client Tier. Do you have some better suggestion?
Is it nessary?
or, We use a control class to tp_call the service?

Similar Messages

Calling Remote interface from client

Hi there!
I am working on a BMP (using weblogic 6.1)
My problem is - How do I contact remote interface from client. In my jndi tree I have mentioned only Home interface. Right now I am calling my remote interface like this:
//contact home interface
Object obj = ctx.lookup("APIHome");
APIHome home = (APIHome) javax.rmi.PortableRemoteObject.narrow(obj, APIHome.class);
//creating remote somehow - I got this clue from a website
rem = home.findByPrimaryKey(new EntityPK("test1","test2"));
//calling getter & setter methods
rem.setWidth()
rem.getId();
This works...but doesn't make any sense to me. Why should we initialize remote interface as above. Or is there any other option. Can somebody please explain me more clearly about this concept.
Thanks very much
regards
-Manasvi

The HomeInterface contains two types of methods - create and find. The create methods create an instance of the entity bean(i.e., a record in the database) and the finder methods finds an existing record in the database, constructs an entity bean representing this row and returns the remote interface of this bean to the client for further manipulations.

How to install only client tier on Client Machine

Hi,
Presently in Server the Hyperion is Installed, now i need to install Hyperion (Client machine ) & configure on Client machine and configure the Server database. while installing the hyperion on client machine should we select all the Services products check boxes (i.e) Client Tier, Web Server, Web Application Server & Service Tier --- or only the "Client Tier" products check boxes should be selected? and this client machine should be accessed by the onsite person.
Please help on this!!!
Waiting for your positive response....
Thanks,
Ravinder
Edited by: 809788 on Dec 22, 2010 10:41 AM

NielOlsson wrote:
If you just need the Run Time Client for Essbase installed on a machine, the easiest and quickest way to get it done is by using the installation for the Excel Addin. It is a much smaller and will install more quickly.Depends on version, in version 11 the standalone excel addin does not include the client as part of the installation.
Cheers
John
http://john-goodwin.blogspot.com/

ACE deployment with two interface for client side

/* Style Definitions */
table.MsoNormalTable
{mso-style-name:"Table Normal";
mso-tstyle-rowband-size:0;
mso-tstyle-colband-size:0;
mso-style-noshow:yes;
mso-style-priority:99;
mso-style-parent:"";
mso-padding-alt:0cm 5.4pt 0cm 5.4pt;
mso-para-margin:0cm;
mso-para-margin-bottom:.0001pt;
mso-pagination:widow-orphan;
font-size:11.0pt;
font-family:"Calibri","sans-serif";
mso-ascii-font-family:Calibri;
mso-ascii-theme-font:minor-latin;
mso-hansi-font-family:Calibri;
mso-hansi-theme-font:minor-latin;
mso-fareast-language:EN-US;}
In a ACE router mode deployment, I have a single context configured with two interface for server side and two interface for client side. In this situation how can we meet the demands of customers arriving from both networks? How can the ACE handle the client request if we configure one default-gateway to each network?
Regards,
Egomes

Enable "mac-sticky" comand under each client inteface.
It will ensure that ACE sends the response to the MAC address from which the request to the VIP was recieved.
For more details
http://cisco.biz/en/US/docs/interfaces_modules/services_modules/ace/v3.00_A1/command/reference/if.html#wp1033275
HTH
Syed Iftekhar AHmed

Lookup Local Interface from client app

I have had an entity bean running using the remote interface.
When I convert over to using a local interface I have problems
with the jndi lookup. My environment is JDK 1.4, J2EE 1.3.1, Win 2k.
The deployment using the J2EE RI works fine.
I need to know what changes to the client code I need to make
to locate the bean using lookup().
I have tried two versions of the lookup:
// same as the version which workds for the remote interface
Properties p = new java.util.Properties();
Context ctx = null;
p.put (javax.naming.Context.INITIAL_CONTEXT_FACTORY,
"com.sun.jndi.cosnaming.CNCtxFactory");
p.put(javax.naming.Context.PROVIDER_URL,
"iiop://localhost:1050");
ctx = new InitialContext(p);
Object objref = ctx.lookup("LocalSPIConnector");
cat.debug ("GOT THE OBJ REF");
spiHome = (ServiceProviderBeanLocalHome)
javax.rmi.PortableRemoteObject.narrow (objref,
ServiceProviderBeanLocalHome.class);
cat.debug ("AFTER NARROW");
I get the following exception;
javax.naming.NameNotFoundException. Root exception is org.omg.CosNaming.NamingContextPackage.NotFound: IDL:omg.org/CosN
aming/NamingContext/NotFound:1.0
In the J2EE RI I can see that this JNDI is associated with the bean.
Is there a different context factory to be used?
I have tried to use the initialContext and then lookup
various forms of the JNDi name:
a. LocalSPIConnector
b. java:comp/env/ejb/LocalSPIConnector
c. java:comp/env/LocalSPIConnector
d. the classpath to the home interface
All these fail as the name has not been bound

Thanks for the reply.
I have simpliefied the lookup to the following:
Context ctx = new InitialContext();
spiHome = (ServiceProviderBeanLocalHome) ctx.lookup ("ServiceProviderBeanEJB");
I still get the following exception:
javax.naming.NameNotFoundException: ServiceProviderBeanEJB not found
at com.sun.enterprise.naming.TransientContext.doLookup(TransientContext.java:174)
I looked up the deployment descriptor from J2EE RI and took the name
to lookup from the ejb-name:
<ejb-jar>
<display-name>localSPIJAR</display-name>
<enterprise-beans>
     <entity>
          <display-name>ServiceProviderBeanEJB</display-name>
          <ejb-name>ServiceProviderBeanEJB</ejb-name>
I presume that this is the correct name to use.

FileGeneration/Wlappc not including local ejb interfaces in client jar

With the following setting in the EJB source:
@FileGeneration(
          remoteClass = Constants.Bool.TRUE,
          remoteHome = Constants.Bool.TRUE,
          remoteClassName = "ReportService",
          remoteHomeName = "ReportServiceHome",
          localClass = Constants.Bool.TRUE,
          localHome = Constants.Bool.TRUE,
          localClassName = "ReportSvc",
          localHomeName = "ReportSvcHome")
          @JarSettings(ejbClientJar = "dist/ReportFacadeClient.jar")
          @JndiName(remote="service-ReportFacade", local="local-ReportFacade")
          @Session(maxBeansInFreePool = "100",
                    initialBeansInFreePool = "10",
                    transTimeoutSeconds = "0",
                    type = Session.SessionType.STATELESS,
                    defaultTransaction = Constants.TransactionAttribute.SUPPORTS,
                    ejbName = "statelessSession",
                    enableCallByReference = Constants.Bool.TRUE)
Along with the "<ejb-client-jar>ReportServiceClient.jar</ejb-client-jar>" entry in the ejb-jar.xml
the ant build script invocation of wlappc successfully creates the "dist/ReportFacadeClient.jar" file as specified which includes the Remote Home and Remote interface, however the local definitions are absent.
It is confirmed that the wlcompile does create the local implementation and interface files, they are just missing from the client jar.
Do I need to manually append them to the jar or is there a configuration setting that I am missing to have this done automatically as is is done
for the remote interface?
Thanks.

Hi,
the local interface and local home is for local client which is within the same application (.ear). So local client needn't any client jar. it can always load the classes (local interface, local home, etc. ) it needs.
so there isn't needs to put local interface and local home to a client jar.
the client jar is for client out of the application, and it will be a remote invocation certainly.

Caching images in the client tier

Hi,
I've a JSP web application with images.
In that application, two HTML pages are generated. Each HTML page has the same image im.gif.
Everytime a navigate from one page to the other, the image im.gif is always loaded from the web server.
I would like to keep the images cached in the client workstation.
How can I do that?
thanks a lote
apaf

Well, generally when an image is loaded the path of the image is loaded in the temporary internet files of your browser(IE) and if the location of the image is from the same folder in the web/application server then the browser first checks the Temporary Internet files to get the image. if it finds then it loads the image from there only. This normally happens unless you specify response.setHeader("Expires","-1") or something like that to specify the browser to always take from the web server.
thanks
Hi,
I've a JSP web application with images.
In that application, two HTML pages are generated. Each HTML page has the same image im.gif.
Everytime a navigate from one page to the other, the image im.gif is always loaded from the web server.
I would like to keep the images cached in the client workstation.
How can I do that?
thanks a lote
apaf

Problem accesing Executable on remote CPU through webb panel interface on client computer

Hi,
I am using LabVIEW 2009 to acces a program "Test.exe" in a server computer. I take it from the forums as it should be possible to bulid a Test.exe with Publishing Tool functionality so its panel can be accesed only with a browser from a client computer. This is how it is setup.
Server CPU (pesno111.company.se):
Labview Run time Engine 2009 SP1
Activated NI License manager
Everything installed from an Installer that also had NI Labview 2009 SP1 Deployable License
Then Test.exe is started and its Test.ini looks like this:
[Test]
server.app.propertiesEnabled=True
server.ole.enabled=True
server.tcp.serviceName="My Computer/VI Server"
server.vi.propertiesEnabled=True
postScriptLevel2=False
WebServer.Enabled=True
WebServer.RootPath=C:\Program Files\National Instruments\LabVIEW 2009
WebServer.TcpAccess="c+*"
WebServer.ViAccess="+*;-Power Spectrum Measurement.vi;-Power Spectrum Measurement.vi"
DebugServerEnabled=False
DebugServerWaitOnLaunch=False
The Test.html file (see attachment) is also placed on the server computers path C:\Program Files\National Instruments\LabVIEW 2009 .
I try to acces the Test.exe from a browser in the client computer with the following path http//pesno111.company.se/Test.html
but it doesnt work. Any ideas?
Attachments:
Test.txt ‏1 KB

Hi Björkis
I would start by checking that I've followed the instructions in these two tutorials:
Remote Panels in LabVIEW -- Distributed Application Development
Developing Remote Front Panel LabVIEW Applications
Also, could be a good idea to look into if you are behind a firewall or proxy as this could cause a problem.
Best Regards
David
NISW

Getting attribute properties from client tier is too slow

Getting properties for view object attributes is too slow, because a called to the server is made for every attribute.
I noticed that when a property is gotten for an attribute all properties are retrieved for it, but I couldn't found a way to get all properties for all attributes in the ViewObject.

See ApplicationModule.fetchAttributeProperties and it's usage in JClient in JDeveloper 9.0.3

Location of stubs, skeletons, remote interface ,client and server files

I have a question to the subject mentioned above :
In a training example for RMI I red the following :
.... stubs, remote interface and client files into
client location
... skeletons, remote interfaces, server files and stubs
into server location ....
I understand that with the exception that the stubs must also be located at server side. My understanding is
that it is enough if those reside only at client side. Is that
right or wrong ?
Thanks for your comment.
Regards,
Oskar

The stubs must be available (in the classpath) on the server side. This is because when a remote server object is exported, the RMI runtime creates an instance of the stub (instead of the server) and sends it whenever a reference to the server is encountered. In order to create (and then serialize) the stub, its class file must be available on the server.

Servlets in Multi tier Architecture

Hi
We plan to use a three tier architecture with
Client --- Applet (JDK 1.2)
Middle tier -- WebServer and servlets
Database Server -- Oracle 8i
Our application should have data entry for several (5 - 12 ) tabs each consisting of around 15 fields . A few Jtables will also be used .
Arounf 5 to 10 validations or queries are required to be done with the database in the applet. Around 300 entries will be made by 12 different users in a day.
Is it advisable to use the above architecture ?
Is it required to use Enterprise JavaBeans ?
Will the use of servlets bring down the validations ?
Overall is our architecture feasible for the requirement ?
We will be greatfull to your suggestions
Please mail to the folowing id also
[email protected]
N.Suresh
null

<joemessina> wrote in message news:202463294@jserv5...
Scenario
I am currently using a combined-tier architecture (Servlets & EJB in same WLS instance) on a WLS Cluster.
I would like to keep to option of going to a multi-tier architecture (Servlets & EJB in different WLS instances) on a WLS Clusteropen without having to change application code.
Questions
1. If I code & deploy my EJB?s with remote interfaces only, will WLS automatically make local method calls to my co-located EJB?swithout me having to set up the local interfaces?
It depends on version of weblogic. 5.1, 6.5 and 7.0 did it automatically.
8.1 requires to set it in weblogic-specific bean's descriptor (weblogic-ejb-jar.xml).
2. If so, is there any reason to ever code & deploy local interfaces other than for entity beans?No, there is no such reason.
3. Is there a standard practice regarding the coding & deployment of local & remote interfaces for combined-tier & multi-tierarchitectures?
Sure. Don't use local interfaces except when defining CMR relationships.
I know this all sounds very affirmative, but that fact is that by the time
local interfaces arrived, all J2EE vendors with weblogic pioneering already
provided implicit and explicit colocation optimization, that was the main
Local's promise... So, Local's use is limited to defining CMR.
Regards,
Slava Imeshev

Client/server/web application

My application will be deployed as client/server application and as well as web application. An database is used to keep the persistent data.
For the client/server environment, I will need client tier, application server tier, and the database tier. For the web applicaiton, I will need web interface, web server, and the database tier.
My question is that since the application will be deployed as both client/server application and web application, how to leverage the components, so the application server and the web server has less code duplication.
Is there any guideline for designing such an architecture?
The application uses J2SE, and Tomcat is the servlet engine.
Thanks for any input /danclemson

Your business logic should be written so that it can used from anywhere. Command line, GUI, webapp, it's irrelevant. Likewise with the db layer, so those will be exactly the same. Then you just put whatever front end you want on it. Now, if you're talking about having the same server used for both at the same time, that's a different question. But it sounds like you're asking about code.

What tier goes where

Hi,
with a web (jsp) application, the tier architecture is simple:
Database tier -> middle tier (webserver) -> client tier (webbrowser)
But what about JClient apps.
Database tier -> middle tier (bc4j) -> client tier (jclient) ?
Where does code execute. If I use a viewobject to populate a JTree, does it 'run' on the middle tier (application server), or does it run on the client machine in the jclient application? What and where's exactly the separation between gui and middle tier?
In a web environment, the browser is the 'thin' client, which knows only html. All business logic is performed on the server. Is the JClient situation comparable? Or is a jclient a much less thin client?

As you're familiar, BC4J allows you to build J2EE-compliant apps with a clean, logical three-tier design. You can then choose to deploy your application as a physical two tier application, or a physical three-tier application as your needs require. These rules hold, regardless of the client implementation technology.
Two concrete examples of a physical two-tier physical deployment are:
[list=1]
[*]JClient application talking to BC4J appmodule in local mode
[*]JSP pages using BC4J datatags talking to BC4J appmodule in local mode
[list]
Two concrete examples of a physical three-tier deployment are:
[list=1]
[*]JClient application talking to BC4J appmodule deployed as an EJB Session Bean in a J2EE Container on another machine
[*]JSP pages using BC4J datatags talking to BC4J appmodule deployed as an EJB Session Bean in a J2EE Container on another machine
[list]
Of course, the degenerate case of the last example above occurs when the JSP pages and the EJB Session Bean actually reside on the same J2EE container, then you can use the EJB Session Bean option of BC4J with local interfaces.
Regardless of the UI layer you're using, your client works with the set of BC4J interfaces in the oracle.jbo.* package.
What changes in the two deployment scenarios is the classes in the JBO framework that implement these common interfaces.
[list]
[*]In a physical two-tier deployment (also known as "local mode"), the interfaces are implemented by classes in the oracle.jbo.server.* package.
[*]In a physical three-tier deployment, the interfaces are implemented by classes in the oracle.jbo.client.* package (and its oracle.jbo.client.remote.* "sub"-package.
[list]
This is transparent to your application code since you are working with the interfaces.
When you use the remote mode, the bulk of the implementation stays on the EJB tier inside your session bean. What travels to the client are collections of value objects which are managed by a client-side value-object cache that BC4J implements for you (but which you do not need to manage yourself). If you are, say, browsing the results of a query that has scrolled through 1000 records, BC4J will keep a "window" of rows of value objects on the client for you, where the size of the window is set via the setRangeSize() method on the view object you're working with.
BC4J is also designed to keep its client-side value object cache kept in sync with any changes that occur in the business objects in the middle tier. For example, say you have some business logic coded into your Employee business object that increases an employee's salary by $1000.00 when their job category goes up a level. And let's say your client is working with a view of the data that shows:
Empno    Ename    Salary     JobClass
1234     Ivo      4321         4If the client updates the value of "JobClass" from 4 to 5, the attribute change on the client-side value object eventually makes it to the middle tier -- immediately if you are using the SYNC_IMMEDIATE mode, and on the next row navigation, row validation, or custom method invocation in the case of our SYNC_LAZY mode. In the middle tier, BC4J syncs the change in the client-side value object "row" of this view object query result and sets the "JobClass" view row attribute in the middle tier. Since view objects cooperate with entity objects, the setting of the "JobClass" on the view object row internally delegates to an attempt to set the "JobClass" attribute on the underlying entity object instance representing employee #1234 (which was created in the EO cache as this row was queried in from the database). Your business logic in the setJobClass() method at the Employee entity level contains the logic that decides that, based on the increase in job class, the salary should get incremented by $1000, so it calls setSalary() like this:
private static final Number ONE_THOUSAND = new Number(1000);
public void setJobClass(Number value) {
    setAttributeInternal(JOBCLASS, value);
    // If new job class is greater than old job class, increase salary by $1000
    Number prevJobClass = (Number)getPostedAttribute(JOBCLASS);
    if (value.compareTo(prevJobClass) > 0) {
      setSalary(getSalary().add(ONE_THOUSAND));
}Part of the functionality of BC4J's unique "Value Messenger" design pattern implementation is that the framework keeps track of the "side-effects" of any middle-tier activity and automatically returns any relevant changes to the client-side value object cache to keep it in sync in the same round-trip that caused the activity to occur. In this example, the client is looking at a value object with the "Salary" attribute for employee #1234 and this employee's Salary has changed as a result of having set the JobClass attribute.
The net effect is that the user types in a new job class of 5 and tabs to a new field, and the updated salary of 5321 appears automatically.
Empno    Ename    Salary     JobClass
1234     Ivo      5321         5 <---------This attribute changed by the user
                     \_______<_______ The updated salary (increased by $1000) appearsThis works both in local mode or 3-tier mode for JClient, JSP, or any of our supported "View-Layer" technologies that bind to the standard BC4J client interfaces in oracle.jbo.*
So, in short, a BC4J JClient app that's deployed as a 3-tier application is a thin client with a small cache of value objects for view objects with active iterators open on the client.
Let me know if you have more questions on this subject.

FR BC4J: publish EntityImpl.getPostedAttribute in ViewRow interface

Would be nice if getPostedAttribute(int) from EntityImpl would also be available in the oracle.jbo.Row interface.
We would need this for some validation stuff at client side.
Thanks, Markus

ok i can understand that, but hasn't this already
happen?
e.g. for a ViewCriteriaRow a refresh, lock, revert,
setNewRowState, removeFromCollection,
removeAndRetain, getKey does not make many sense.
But VCR is inherited from Row and therefore the API
user has already to investigate if those methods are
somehow implemented or not (btw. the API doc is not
very helpful regarding this).
So i do not see a big problem for another method that
is only implemented in some subclasses.
Perhaps there is a need for a new "DatabaseRow "
interface to put those methods and constants in?
I do not see another place to publish this
functionality to the client.
Thanks, MarkusMarkus:
That's right. The Row interface is primarily driven by our needs to access ViewRow and EntityRow in abstract way.
As getPostedAttribute is only available on EntityImpl and not on ViewRowImpl, I don't feel it belongs to Row.
If you want this method to be added to Row, so that the API would be available in the CLIENT tier, remember that EntityImpl is not available in the CLIENT tier. Specifically, if you're running your app in 3 tier config, you have no access to EntityImpl in the CLI side. So, making it available on the Row interface will not help.
Thanks.
Sung

What is thin client ?

Please expalin me what is "Thin client? and what is seemless connections among all the 4 Tiers in HFM Applivation? and what is Classic HFM Application? and What is Artifacts?

Hi,
If we access a clients from web based are thin clients. We can access HFM through workspace or direct HFM weblink.
The client tier contains the user interface and the ability to communicate with the application tier. You can display data and metadata, enter data, and maintain metadata in this tier.From the Web server tier, you access the Web-enabled portions of Financial Management.The middle tier contains the domain intelligence and connections to the relational database and The data tier contains the relational database and all Financial Management data and metadata.
we can create two types of application in HFM classic or EPMA. Classic applications are individual to each application.
In EPMA we can share same dimention structures among multiple applications. dimension library maintains the dimension and application library maintains the all the application whinch is created in EMPA only.
Kiran

Interface to Client Tier

Similar Messages

Maybe you are looking for