- Log into the administrative console.
- Expand Security and click SSL certificate and key management. Under Configuration settings, click Manage endpoint security configurations.
- Select the appropriate outbound configuration to get to the (cell):MyComputerNameNode07Cell:(node):MyComputerNameNode07 management scope. (The nodes above are samples only, and are different for different machines)
- Under Related Items, click Key stores and certificates and click the NodeDefaultTrustStore key store.
- Under Additional Properties, click Signer certificates and Retrieve From Port.
- Enter hostname in the host field (e.g. www.icodejava.com), enter 443 in the Port field, and hostname_cert (e.g. www.icodejava.com_cert) in the Alias field. You can of course use your own alias name. Remember the hostname is the host from which you are importing the certificate.
- Click Retrieve Signer Information.
- Verify that the certificate information is for a certificate that you can trust.
- Click Apply and Save.
Congratulations, you have successfully import SSL Certificate from a host to IBM Websphere Server through the admin console in an easy set of steps.
The followings are some commonly asked interview questions related to Web Services. These questions are alphabetically sorted. For other interview questions on other technical topics, go to my page here.
- Define SOAP?
- Explain the web service architecture?
- How do you generate web service client from WSDL files?
- How do you test a web service?
- Name few standards used in web services.
- What are some WSDL operations?
- What are the common components of web service?
- What is a bottom up approach?
- What is a provider and a consumer?
- What is a response caching?
- What is a top down approach?
- What is a web service protocol stack?
- What is a web service?
- What is an end point?
- What is REST protocol?
- What is SOAP-UI?
- What is UDDI?
- What is WSDL?
- What is XML RPC?
- What kinds of tools can you use for creating RESTful Web Services?
- Why would you choose REST instead of SOAP?
Even though comparing SOAP and REST Webservices will be like comparing apples and oranges because one is a protocol the other is an Architecture, I have made an attempt to expose twenty differences aimed at helping people make a decision on using one vs another. Also if you are new to SOAP Webservices, read my article here on using SOAP UI tool to demonstrate the use of SOAP Request Response.
||Simple Object Access Protocol
||Representational State Transfer
||SOAP Uses XML which is not very efficient and may not be a good fit for some languages. SOAP can be slow and is definitely a heavyweight choice.
||REST is a lightweight protocol and is fast.
||SOAP has one common and expressive format
||REST response can be of multiple types.
||Security can be implemented using WS-Security, WS-Trust and WS-SecureConversation
||Security is implemented in terms of HTTP andSSL
||SOAP can be used over other protocols not just HTTP such as HTTPS, SMTP, TCP, UDP, JMS. SOAP itself is a protocol.
||REST is completely based on HTTP and URI’s. REST is not a protocol in itself
||End to end communication is reliable via WS-ReliableMessaging which does retries. The client does not need to retry.
||REST expects the client implementation to handle communication failures by retrying
||More complex due to client creation requirements. SOAP also has several parts to it such as envelope, Header, Body, Attachments and Fault.
||Raw HTTP calls via GET, POST, PUT, DELETE and is simpler invoke
||The request and response are in XML format.
||The response object can be on several formats such as XML, JSON, RDF etc.
||Exposes Operation and types of data.
||No particular standard
||Support ACID transactions via WS-AtomicTransaction
||No particular standard
||SOAP Reads cannot be cached
||REST reads can be cached.
||SOAP cannot use REST
||RESTful architecture may use HTTP or SOAP as the underlying communication protocol.
||Less scalable than REST
||More Scalable than SOAP
||Works pretty well in distributed enterprise environments
||REST assumes direct point to point communication
||SOAP is extensible in the forms of WS* standards.
||There are no particular standards in extending REST.
||SOAP has a steep learning curve
||REST has a smaller learning curve.
||SOAP interfaces are not uniform
||REST provides a uniform interface.
||SOAP provides a format contract between the provider and consumer
||There is no formal contract between the provider and consumer in a RESTful webservice.
||SOAP provides mechanism for stateful communication
||REST is a totally stateless operation.