I'd like to connect to the JMX server on a WebSphere application server instance using a SOAP over HTTP connector but I don't know where to find a compatible SOAP protocol provider.
I get a MalformedURLException when using a JMXServiceURL starting service:jmx:soap:... that says Unsupported protocol: soap. What jar(s)/protocol provider string do I need to include?
Update: I am playing with a standalone Java client.
Unfortunately, IBM only provides a proprietary API to connect with SOAP over HTTP. They don't provide an implementation of the standard JMX API for that protocol. I faced the same issue and I developed such a connector (which is basically a thin JMX compliant wrapper around IBM's proprietary API), which is now available as Open Source. You can find more information here:
https://github.com/kszbcss/xm4was/wiki/JmxClientConnector
The following document describes how to set up a standard JMX tool (VisualVM) to use that connector:
https://github.com/kszbcss/xm4was/wiki/VisualVMHowTo
As you can see from these documents, after adding the relevant JARs to the class path and setting the necessary system properties, you would simply connect using wssoap as protocol.
Check that in the path Application servers > <server_name> > Administration services > JMX connectors the relative SOAPConnector exists and is Enabled.
Refer at Infocenter for more information.
Related
The REST API for Kafka Connect is not secured and authenticated.
Since its not authenticated, the configuration for a connector or Tasks are easily accessible by anyone. Since these configurations may contain about how to access the Source System [in case of SourceConnector] and destination system [in case of SinkConnector], Is there a standard way to restrict access to these APIs?
In Kafka 2.1.0, there is possibility to configure http basic authentication for REST interface of Kafka Connect without writing any custom code.
This became real due to implementation of REST extensions mechanism (see KIP-285).
Shortly, configuration procedure as follows:
Add extension class to worker configuration file:
rest.extension.classes = org.apache.kafka.connect.rest.basic.auth.extension.BasicAuthSecurityRestExtension
Create JAAS config file (i.e. connect_jaas.conf) for application name 'KafkaConnect':
KafkaConnect {
org.apache.kafka.connect.rest.basic.auth.extension.PropertyFileLoginModule required
file="/your/path/rest-credentials.properties";
};
Create rest-credentials.properties file in above-mentioned directory:
user=password
Finally, inform java about you JAAS config file, for example, by adding command-line property to java:
-Djava.security.auth.login.config=/your/path/connect_jaas.conf
After restarting Kafka Connect, you will be unable to use REST API without basic authentication.
Please keep in mind that used classes are rather examples than production-ready features.
Links:
Connect configuratin
BasicAuthSecurityRestExtension
JaasBasicAuthFilter
PropertyFileLoginModule
This is a known area in need of improvement in the future but for now you should use a firewall on the Kafka Connect machines and either an API Management tool (Apigee, etc) or a Reverse proxy (haproxy, nginx, etc.) to ensure that HTTPS is terminated at an endpoint that you can configure access control rules on and then have the firewall only accept connections from the secure proxy. With some products the firewall, access control, and SSL/TLS termination functions can be all done in a fewer number of products.
As of Kafka 1.1.0, you can set up SSL and SSL client authentication for the Kafka Connect REST API. See KIP-208 for the details.
Now you are able to enable certificate based authentication for client access to the REST API of Kafka Connect.
An example here https://github.com/sudar-path/kc-rest-mtls
Can someone explain how to read JBOSS system variables (e.g. jboss.bind.address) in CAMEL? We are using CAMEL as part of a web-service which talks to several other backend web-services and we want the piece of code that creates an endpoint to bind to a specific network interface. This information is
Well it should be working with
System.getProperty("jboss.bind.address");
According to http://cxf.apache.org/docs/jmx-management.html, CXF provides JMX monitoring for Web Service providers. The documentation is silent about whether it works for SOAP clients or not. Metro, on the other hand, clearly says that client monitoring is supported as well. The only reason I am looking at CXF is because it provides connection pooling which Metro does not, to my knowledge.
So my question really is, does anyone know if CXF supports client side JMX monitoring for SOAP clients? If yes, can you give some pointers? If not, is there a way to achieve connection pooling with Metro?
To answer my own question, CXF does not support client side JMX monitoring. It has better support than Metro for server side monitoring, provided CounterRepository bean is configured.
I would like to know the difference between IBM HTTP Server and Wepsphere Application Server. Also i am planning to use WAS. Do i still need the IBM HTTP Server?
From here:-
IBM HTTP Server
IBM® HTTP Server is a full-featured web server that is included with
other products such as IBM WebSphere® Application Server at no charge.
You can use this web server for projects that do not warrant the
expense of a priced and supported HTTP server. The IBM HTTP Server is
based on the Apache HTTP Server and provides a rich set of Apache
features in addition to IBM enhancements.
From here:-
Wepsphere Application Server
IBM® WebSphere® Application Server offers options for a faster, more
flexible Java application server runtime environment with enhanced
reliability and resiliency. It supports single server environments and
medium-sized configurations, as well as dynamic web applications
requiring web tier clustering over multiple application server
instances.
Do i still need the IBM HTTP Server?
Wiki has the answer for it:-
It works with a number of Web servers including Apache HTTP Server,
Netscape Enterprise Server, Microsoft Internet Information Services
(IIS), IBM HTTP Server for i5/OS, IBM HTTP Server for z/OS, and IBM
HTTP Server for AIX/Linux/Microsoft Windows/Solaris. It uses port 9060
for connection as the default administration port and port 9080 as the
default website publication port. In case you install more WebSphere
instances these values will be changed.
A http server is used for routing web requests to a WAS in a typical enterprise scenario. If you are building small apps, and do not need ejbs, just use the http server. If you need ejbs, just use WAS. However, if you need functionality like routing requests to WAS because you do not want the user to hit the WAS directly for security reasons, then use HTTP in front of WAS.
WebSphere is an implementation of J2EE (originally Java 2 but versions handle up to J6EE). This varies from a normal web server in that the latter typically had the task of running scripts or programs using operations that were quite expensive for CPU load. Modern web servers do not have as much penalty but Java based solutions still have their advantages.
For test/dev environments, one does not need to have a web server in front. One can go directly to a WebSphere port (often port 9080) that provides a Java web implementation and not have the administrative burden of the care and feeding of a web server. On the other hand, IBM recommends using a web server for production (especialy for larger production loads). If one does use a web server, there are several that are supported. IBM HTTPS Server is a blue-washed version of Apache (there are some modules that are not supported but there are also lots of extra features to bind easily with WAS).
All the answers are good so let me give my cents ,
Websphere as other java applications, was made to work with dinamic contents .
apache or IHS that is apache IBM plugins can handle with all kinds of http/https requests , static , dinamic , proxy ,cache at the client tags, balance and so on ...
just using apache over java aplications is not the best ,
the best is allow apache handle all static downloads without call it from application server ,
like images and fixed htmls and left application server handle the just dinamic contents .
at this way we can optimize the environment , so development should create a pattern to dispose static and dinamic at different virtual direct like /jsp for dinamic and the rest as static , if not apache cache can be used instead for not overload the application server .
to make the story short , apache is so powerful ans can help a lot the application server sparing the work , a simple and effective usage is done to forward the port using default port 80/443 for http/https instead usual high ports on java application servers , make the apache deliver https is a best option too , instead left java application server care of it , so there is a lot of reasons to use Apache or IHS in front of application servers.
Apache CXF: It seems that failover feature is available, but for clients. I need to create a service that is binded to a JMS queue of a particular JMS server. The JMS provider(TIBCO) has capability of failing over. Is there a way in which I can allow my service to failover to another JMS server at runtime and publish it there? If cxf is not capable of doing this, is there any other framework which allows failover feature for publishing services over JMS?
Vidish,
Server :
The TIBCO EMS administrator needs to configure the FT connection factory and provide the connection factory name and URL details to you. Configure those details in your JMS configurations - that's all needed for server.
Client :
TIBCO JMS API provides failover mechanism. Sample code is available in TIBCO EMS installation folder.
Joy