I use OGSA-DAI as a middleware for data integration. The problem is that OGSA-DAI works with RDF, XML, Relational and Flat File Data Resources. However, in one case data are provided through a "local" middleware, i.e. as WSO2 Data Services.
My question is whether there is an implementation of a JDBC driver as a wrapper of a WSO2 Data Service.
No, there is no such thing as a JDBC driver wrapping a data service. Basically a data service is a typical SOAP web service, or a REST service. And for SOAP web services, you will get a WSDL, which can be used to code generate stubs, and these stubs can be used to call the target data service. So it will not make sense to map these web service operations into a JDBC driver.
Cheers,
Anjana.
Related
I have a system (kind of aggregator) that integrates with hundreds of different SOAP services - most of them do the same business functionality, but each service having different data structure in SOAP request & very few having 2 API calls to complete one transaction.
The present service integration workflow is
create stubs from WSDL
map data to the generated stub api
setup a new endpoint to fire this api
I see this a repeated, unintelligent work & requires development effort for every new service integration.
Was there different approaches to integrate with lot many systems? Any libraries that can generate soap requests based on configurations, or I have to rely on some Java SOAP, Spring lirbaries to create custom SOAP xml request from my own configurations? I see Spring's WebServiceGatewaySupport for webservice client but requires stubs created from wsdl?
Is it wise to define soap request xml as templates for every service, generate xml with input data?
Other ways I thought was to develop each integrations as independent microservice layered under an API gateway that routes each requests to specific service. But this design approach will have hundreds of services running, consuming more resources (in case of Spring boot).
Generate stubs & deposit the jar to disk, load this jar with a classloader & use the stubs using reflection - not so simple, I believe.
Use of serverless looks promising but is not possible immediately.
I have a spring mvc application which runs correctly,now another colleague wants to call the same functions from another application but he needs REST URL of my functions.
how is it possible to provide the same functionality through spring REST?
is it just with new annotations .please provide some resource to show me how to do it.
when server has a service, only legal clients which had any contracts with server can access it. And clients can use service by the way such as: use RestTemplate to get/post request to URL of service, and clients can get data as JSON, or XML type if you have an equivalent object as this image:
Also, a service can be support as a interface, ex: google search is a service supported by google, but it's not rest service.
If you know each other URL address you can consume each other REST API from java code by using RestTemplate object.
I would advise you to go over the Spring starter guide which deals with that issue, here is the link (Consuming a RESTful Web Service):
https://spring.io/guides/gs/consuming-rest/
I'm developing a new application based on Spring MVC and Hibernate for data access.
I want the data access layer to be running on a separate application server, preferably JBOSS.
I want the data access layer to be running behind a firewall.
How can I achieve this?
Right now I'm concerned about hibernate lazy initialization in this scenario. Would there really be any problems with Hibernate lazy initialization?
There could be some performance penalties to this approach - the IO will be a bottleneck. However, Spring Remoting allows you to easily achieve this.
Create an interface for you DAO.
Implement the concrete implementation.
Use spring remoting to export the interface.
Inject the interface - from your apps point of view its just something that implements the interface. It doesn't care the the calls are being fired off to the remote server.
The mechanism for achieving this is called DynamicProxies - a Java SE feature. DynamicProxies allow you to provide a class that responds to the method calls on an interface at runtime. In this case the method calls are dispatched across to the corresponding methods on the remote server.
Both the service layer and DAO layer servers should be behind the firewall on the same domain.
From the UI, use REST web services to fetch the data from application server (hosting the DAO's and Transactional services). Annotate the entity classes with #Proxy(lazy=false) to avoid lazy loads of entities. For the server to validate the clients (web application querying the business layer behind firewall), use client identity certificates, you can use Bouncy Castle CMS APIs to validate the identity, trust and message integrity. If you have SSL offloaders in network, use detached signatures in http(s) headers.
im trying to understand where WSDL's fit in, in a typical web service backend application. i am coming from a Spring background and in my experience so far, in Spring, each url request gets mapped to a specific controller class via a dispate servlet running in the web container. you can specify which url matches a given controller via xml config or from annotations.
is using a WSDL the same thing as using an xml config file to map url requests to java objects?
Thanks in advance. im moving from Spring to standard j2ee/EJB3.
WSDL is just a description of Web Service interface, most Web Service systems generate those descriptions on fly like for example when you create asmx web services you can generate WSDL on fly by typing http://yourhost/yourwebcontext/yourwebservicename.asmx?wsdl and it will return you the description of that web service. Then you can use a tools that generate stub proxies for coding using those descriptions automatically, for example in Visual Studio when you add an Web Service Reference those operations are done automatically
No, WSDLs are not like a dispatch servlet.
A WSDL file is a description of a web service (SOAP, REST, etc.). A WSDL can (theoretically) be used by anyone to generate executable code which consumes the web service described by that WSDL.
From the WSDL tag info:
"WSDL" stands for "Web Services Description Language." It is an XML language used to describe a web service to code that wishes to consume it. It describes the messages sent and received, the possible faults, and the communication and security requirements.
From WSDL Essentials:
In a nutshell, WSDL represents a contract between the service requestor and the service provider, in much the same way that a Java interface represents a contract between client code and the actual Java object. The crucial difference is that WSDL is platform- and language-independent and is used primarily (although not exclusively) to describe SOAP services.
Using WSDL, a client can locate a web service and invoke any of its publicly available functions. With WSDL-aware tools, you can also automate this process, enabling applications to easily integrate new services with little or no manual code. WSDL therefore represents a cornerstone of the web service architecture, because it provides a common language for describing services and a platform for automatically integrating those services.
I am really confused about when to use WCF and when to use ADO data services in my website ajax calls.
I always make my javascript code call a webservice to get data from server "ajax".
But while reading in both WCF and ADO data service, i am not sure when to use each and when not use?, and if they replace each other in my case? or can live side by side?
Can anyone make me understand in points when to use which in ajax websites?
ADO.net Data Services is a library to expose a datasource thru Wcf.
As such the functionality exposed by an Ado.net Data Service is for reading, updating, creating and deleting records in that DataSource.
With Wcf you can expose any kind of functionality (that's why an ADO.net Data Service is a WCF service)
So to answer your question, if your client application needs direct access to the datasource then Ado.net Data Services will provide that functionality out of the box.
If the client needs to talk to a Business Layer which in turn will access that Data Access Layer then you will expose that Business Layer as Wcf Services.
You could well use both approaches in the same application:
Exposing some tables directly using ADO.net Data Services
Exposing Business Logic with a WCF service
In a banking application for example you would not expose the Account table because you want to enforce some business rules.
In a simple ToDo list application you could expose the Tasks table using ADO.net data services because there is no business logic to be applied (note that I said SIMPLE ToDo list app)