Difference between SOAP over HTTP and SOAP over JMS?

Reason for choosing JMS in most cases is reliability. But there are other things that come in mind whether to choose JMS or HTTP. Reasons to go with HTTP:

Firewall friendly (web services exposed over internet) Supported on all platforms (easiest connectivity in b2b scenario) Clients can be simple and lightweight Assured delivery and/or only once delivery Asynchronous support Publish/subscribe Queuing if better for achieving larger scalability and reliability Better handles temporary high load Large volume of messages (EDA) Better support in middleware software Transaction boundary

Reasons to go with JMS:

In SOA architecture best practice is to use JMS internally (for clients/providers that can easily connect to ESB) and HTTP for connecting to outside partners (over internet). Using SOAP over JMS gives some advantages compared to HTTP, specially related to reliability as you may use the persistence and acknowledgment features built in the standard. The same applies if you need to establish asynchronous communication or need to use the load balancing features provided by JMS servers. We can achieve this using http but the implementation would be much more complicated.

If we do SOAP over JMS, in fact we can do load balancing.. where as with SOAP over HTTP requires additional hardware like IP Sprayers.
Email ThisBlogThis!Share to TwitterShare to Facebook Labels: Business Works, EMS, HTTP, SOAP, Web Services

TIBCO Admin -Transport options local / rv / http

When TIBCO Administrator deploys an application, it creates an application repository which contains information about the application configuration. We can view and change certain aspects of the application repository. TIBCO Admin -Transport options local / rv / http In TIBCO Admin , browse new ear file and go to the path "Edit Application Configuration > Advanced tab" There are two sections Global Variables TIBCO BusinessWorks and Adapters Deployment Repository Instance under the section "TIBCO BusinessWorks and Adapters Deployment Repository Instance" there is Transport drop down box having the options local ,rv and http This transport is that the administration server uses to communicate with the client application.

local

By default, the transport is set to local. This means that the application repository will be sent to the target machine. This allows the application to run independently of the administration server.

If you change the transport from local to another value, the application repository will not be pushed to the target machine, and the application will communicate with the administration server at runtime. The local choice is supported only if the target machines have installed TIBCO Runtime Agent 5.3 or later.

rv

If rv selected, the client application will use TIBCO Rendezvous to communicate with the administration server.

http

If selected, the client application will use HTTP to communicate with the administration server. If administration domain is not initially enabled for HTTPS, and there are deployed applications in the domain that use HTTP to connect to the application repository, the service instances will not restart after they are shut down. In this case, you must redeploy each service instance after changing the transport to HTTPS. The parameter HTTP URL, HTTPS URL is the URL on which the client attempts to connect to the server. What displays depends on whether you configured the server for HTTPS
Email ThisBlogThis!Share to TwitterShare to Facebook Labels: Interview Questions, TIBCO Administration

Exporting an EAR file from Administrator

We can export an EAR file and its configuration file of deployed application in Admin with AppMange command AppManage -export -out c:\temp\ExampleApp.xml -genEar -ear c:\temp\ExampleApp.ear -app root/folder1/ExampleApp -user

<username> -pw <password> -domain <domain name> The deployment configuration file and EAR file are created in the c:\temp folder. The application is embedded in root/folder1/, which is relative to the Application Management root in the TIBCO Administrator GUI. We can export all applications EARs in an administration domain using the appManage -batchExport option. Example, AppManage -batchExport -user <user name> -pw <password> -domain <domain name> -dir c:\temp\test
Email ThisBlogThis!Share to TwitterShare to Facebook Labels: AppManage, TIBCO Administration

TIBCO BW Administration
TIBCO BW Administration is for User Management,Resource Management and Application Management

User Management -Managing authentication, roles, and users. Resource Management -Managing machines, applications, and deployments. Application Management -Creation, configuration, deployment, and monitoring of applications.

Roles and Responsibilities

Various roles are recommended during a BW development project i.e.Domain Administrator,Project Administrator,Building of actual BW solution

Domain Administrator will Configures domains and grants access to different projects and runtime components.

Project Administrator responsible for maintaining a specific server-based project and maintains project templates, common services, global variables, shared resources, and shared schemas.

Developer Builds the actual BW solution.Release / Test / Deployment Engineers optional roles responsible for testing, building EAR files, and deploying EAR files.

TIBCO Administration Domain

A collection of users, machines, and services managed by a TIBCO Administration Server and secondary servers may be added.Here cannot run a master and secondary on the same machine.

Multiple administration domains may exist on one server.Each domain must have an associated master server.Stores user and group information in the domain data store.This can also sync with LDAP for users and groups and supported LDAP servers include SunONE Directory Server, NovelleDirectory, and MS Active Directory.

By default, all machines that belong to a domain are expected to be on the same network subnet.This can use RVRD if access across subnets is required.

Administrator Users and Roles

Maintain ACLs by specifying users, roles, passwords, and authorization levels.Administrator access is given on a per-UI element basis.i.e. Read, write, and administer access.

If using LDAP, you cannot create/rename users or change passwords in the Administrator GUI. Performed through the corporate LDAP. Exception: May change the password for the original admin user. Changing the original admin password also involves using the Domain Utility

on every machine in the domain. Ensure that the Administration Server is running! Members of a child role are automatically members of each parent role.
Email ThisBlogThis!Share to TwitterShare to Facebook Labels: TIBCO Administration

TIBCO Administrator Fault Tolerant Setup

This is about the configuration and the implementation details for Administrator Fault Tolerant SetUp. TIBCO Administrator is widely used to deploy BW processes to different machines in the domain. If the Administrator server is down for some maintenance or hardware related Issues the deployment cannot happen and roll out dates will be affected. To over come this problem TIBCO has provided the feature of fault Tolerant setup 1. Product Versions

Fault Tolerant SetUp is provided with TRA Versions 5.2 and above. The XMLs are available under $TRA_HOME/5.6/template/domainutility/cmdline folder.(modify the XMLs to the current environment.) 2. Configuration

This section talks about the configuration steps. 1.Install Administrator on the secondary server

2.Run create domain script on the secondary server cd /apps/tibco/tra/5.6/bin> . /domainutilitycmd cmdFile /apps/tibco/CreateDomain.xml 3. Run Add Secondary script on the secondary server cd /apps/tibco/tra/5.6/bin . /domainutilitycmd cmdFile /apps/tibco/ModifyLDAPConfiguration.xml 4.Start Administrator on the secondary server