We have more than 2000 business methods which we want to expose as soap web service. We decided to use cxf with apache camel for this. We want to publish all these services from same url since we think management of them would be easier(especially for customers who call many web services). However we also have some requirements like:
method based log enabling
method based setting timeout
method based mtom/base64 setting and etc.
My question is, if its possible to publish all the services from same url(same SEI) and also being able to provide all these requirements. And also if we manage to do this, will it be a good and scalable solution?
method based log enabling
If you have 2000 methods in your business logic, I guess you also have logging. You can define multiple loggers for your webservice and use in every method at your convenience
method based setting timeout
CXF allow to configure ReceiveTimeout at server endpoint configuration, so if you use one endpoint, then the timeout will be the same for all your methods
method based mtom/base64 setting and etc.
MTOM is configured by JAX-WS server, enabling or disabling it. Also the methods will have an specific DataHandler to support it. One endpoint means one MTOM configuration
In this link you can see the http-transport variables set by server. Other utilities like interceptors, bus or fault handlers are also configured by JAX-WS server. Check here if any is of interest
will it be a good and scalable solution?
As stated #kolossus, 2k methods is a solution weird. I do not think you have performance problems, but it will difficult to develop and maintain. Think you can also provide a built client, instead of only the WSDL, that encapsulates several endpoint
Related
We are using SOAP based web services to let end user schedule service appointments. Our portal is WebService client & we have a number of Vendors(who are spread across the globe in various timezones) who are building Webservice Server operations.
We are thinking to build it as a contract first SOAP based web services so that we have tight control(interface based e.g. date-time format should be standard xsd:dateTime etc.) over what can be sent & received as part of XML messages for possible success & error scenarios(via different error codes). We want to keep single client code for all the vendors. We would like to determine
1) Should we think about using RESTful web services?
2) Is there any way the vendors can use RESTful services also if they want at their end(by sticking to our WSDL contract) & we use SOAP at our end
First a little bit about,
REST (Representation State Transfer) is an architecture style to develop webservice. In which data and functionality are considered as a resource and can be accessed via URI (Uniform Resource Indicator). It follows client server architecture and uses stateless protocol (usually HTTP). Typically in REST webserivces resources are acted upon by GET, PUT, POST,DELETE operation. Generally we use JSON to exchange data between client and server. It is light weight.
On the other hand SOAP (Simple Object Access Protocol) is a XML based mesaage protocol. Which is generally used on enterprise level to define their own interfacing and operations as services. It also follows REST architecture.
So basically, it is a RESTful webservice.
Now to answer your question,
It seems you are going to expose your webservice client on enterprise level. Which is going to be used by many vendors to implement their own webservice server.
So, it is perfect, you go with SOAP webservices.
You will define the skeleton of the webservice like Message formats, Operations, binding etc which is called WSDL. It is widely used standard and very easy to understand by any third party. Something called WADL is used for REST services also but it is not very user friendly.
The same contract (WSDL) will be used by your vendors to implement the webservice on their server in Top to Bottom approach using some API, for example JAX-WS.
This way you will have a tighter control over your operations, formats, security etc. in a single contract (WSDL).
Now if a vendor wants to use REST webservice instead of SOAP. You can build a JAVA proxy on top of your client. Which will convert your soap messages into REST to send/receive request/response to REST webservices. But you can not dictate your contract in this approach. Although, You can recommend vendors to build their own proxy to handle your SOAP webservice requests. This way your contract will be intact.
If you are going to expose your webservice client for small applications then it is alright to go with REST but if you are an enterprise and going to expand in future, you should go with SOAP for robust features and easy maintenance.
Disclaimer: please do not consider this answer as really serious.
Well, I think question too abstract. Why do you asking it? Because you see yourself that currently everything is RESTful? Then you'r right. You can do any protocol. But if you will do REST with JSON instead of XML, everybody will thank you. And if you will use 40 years old technology for creating modern service, then probably not. Same for your contractors.
The only advantage SOAP seems to have in your situation is that it is already implemented.
SOAP is a complex standard with unfriendly implementation and verbose implementation - i.e. hard to work with and maintain. Also note that you are not even using it "by the book" since your security is external to it and not using ws-security
REST based interfaces would make your and your users' lives easier. I suggest you take a look at standards and tools like swagger for building APIs.If you're running on premise you can take a look at API gateways like tyk If you're running in the cloud you also take a look at AWS API Gateway
I am proxing huge amount of web services using JBOSS FUSE ESB.
using content based router for deciding the real web services. But, If there is a new services deployed in backend. I am forced to change the proxy details (WSDL) and expose the interface.
which leads to client regenerate the client code again.
Is there any other solution which will allow me to optimize this problem in design level.
Some general thoughts on this but I would need more detail to give some solid advise.
You are proxing the services thus you are not abstracting the services away. You are exposing the services rather directly to the outside via the service on FuseESB.
Typically you would use a ESB to abstract provider and consumers away from each other. This means that you wont expose/proxy the service directly. For example you would create generic operations and data structures. This will allow you to then map the generic interface to the web service implementation that you are providing.
Another approach would be to version the different WSDL's and thus have different versions of the services out there. This will allow you to have client consume the older WSDL's and then migrate them over bit by bit.
I have a spring MVC application setup which provides web services. It has Authentication, ACl's, caching etc..
Key question: call of services from within other services.
I am required to implement a setup which will require a full cycle for such calls, including Access Control and Caching support.
Is it possible to implement this? if so please guide me through because I am stuck with getting a solution..
I am required to implement a setup which will require a full cycle for
such calls, including Access Control and Caching support
Both of these sound like cross cutting concerns which you can handle using Spring AOP. For example Spring 3.1 provides a cache abstraction which will allow you to annotate a service method as #Cache. Spring will then take care of looking up the result in your configured cache provider.
In addition Spring security will provide you with the #Secured annotation which can be used to limit who can call service methods.
If you use these aspects you can avoid creating a service layer filled with code which does the same thing in lots of different places.
For more information check out the docs here and here
I'm investigating integrating a 3rd party web application with PeopleSoft via web services. I'm not that familiar with PeopleSoft. After some initial investigation, it appears that in order to expose any PeopleSoft functionality as web services, you have to do some considerable configuration in the Integration Broker component of the PeopleTools module. It seems that you can either define internal PeopleSoft services with "service operations" and related "handlers" or you can create a PeopleSoft service for an existing "Component Interface." Then, you have to expose that PeopleSoft service as a web service.
Are there any standard, default, out-of-the-box web services available for a PeopleSoft system, or do you always need to go through the steps of defining them in the Integration Broker?
After looking at a system like Salesforce, which has a standard web services API, it seems like there might be something similar for PeopleSoft, but I'm not finding it. Am I on the right track in thinking that the Integration Broker is the only way to go, or am I just not aware of some standard web services API that exposes basic PeopleSoft functionaity as web services?
Integration Broker (IB) is what you need to expose business logic from peoplesoft and consume it with your 3rd party tool, or to consume a webservice from your tool in peoplesoft.
There are some out of the box messages, but most of them are made to have different PIA (PeopleSoft Internet Architecture) communicate.
Be aware, IB components were almost complemently remixed in peopletools version 8.47. So it's important to give your tool's version when talking about IB.
Never heard about a standalone API for implementing web services, outside of the IB framework. IB will use dedicated class to handle sending and reception of your messages. You mention it as the handler. And if a component interface need to be used it will be done throughout this class.
Integration broker is used to setup the basic configurations that will be used in exposing and using web services. this includes making nodes and its routing available for other system to use.
http://docs.oracle.com/cd/B14099_19/integrate.1012/b14060/int_broker.htm
There are many web services available in peoplesoft. you can alsi expose any componemnt as a web services by executing very simple steps.
http://docs.oracle.com/cd/E15645_01/pt850pbr0/eng/psbooks/tibr/chapter.htm?File=tibr/htm/tibr14.htm
Custom web services can also be build.
We don't exactly comply with the XML-RPC spec, but the concepts are nearly identical. A client comes in over HTTP/HTTPS with an XML payload. We respond with an XML payload answering the request. This is primarily machine to machine, so no human to type a username/password. Our construct runs within apache tomcat. We would like to authenticate the request and since not every service is available to every client, we need to authorize the request as well. We have both subscription and per use charging models so it is necessary to log everything.
What would you recommend for both server and client?
HTTP BASIC/DIGEST works fine for most machine to machine tasks, and it handled by the server so your API is unaffected.
It doesn't work as well for interactive uses because it's difficult to "log out" the user without closing the browser.
Otherwise you'll most likely need to alter your APIs to include authentication information and have your methods authenticate that within your code.
Or you could use the classic "login", set a cookie, keep a session technique.
But, frankly, for machine to machine work, HTTP BASIC is the easiest.
edit, regarding comments.
HTTP BASIC is simply a protocol used to present the artifacts necessary for authentication, and it works well for machine to machine web services.
HOW IT IS IMPLEMENTED is dependent on you and your application. Using Java, you can use container authentication and that will provide authentication as well as role mapping. The user -> role mapping is handled in either a data file or database. The URLs protected, and what roles are valid for each URL, is managed by web.xml.
If you continue to add different roles to different URLs, then, yes, you'll need to redeploy that application.
However, if you're just adding new users, then you simply update your file or database. And if you're adding new logic, and this new URLs, then you have to redeploy anyway. If you have a ROLE structure with a fine enough granularity, you won't have to be messing with the web.xml until you actually add new methods. For example you could, at the extreme, create a role per method, and assign them individually to users. Most don't need to go that far.
If you don't want to use container authentication, then write a Servlet Filter to implement your vision of mapping user and roles to URLs. You can still use the HTTP BASIC protocol for your clients, even if you implement your own facility.
If you're looking for an overall generic Java security framework, I defer to google -- there are several, I've not used any of them. I've had good luck with container authentication and writing our own.
#Will
I second the HTTP Basic suggestion, and can testify that it integrates fairly well with Spring Security, which I implemented on top of a legacy application that rolled its own DB-based authentication/authorization logic.