Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
Background:
I work in a organisation, uses hundreds of software systems, we identify which system owns which category of data, then carefully select the data we want to expose to the other systems. then pull them into a single Oracle database.AKA master data.
then each system read the status of the other system through this shared database pattern.
Problem:
access control, data handling, and lack of event notification, logic routing caused us lots of time and effort. We want to add a ESB layer in front of the
Potential Solution:
we are looking at SOA at moment, in specific Enterprise Service Bus Pattern.
we aware there are options like Camel, Mule and ServceMix. But I wander is there any resource, can assists our implementation?
is there any project been done the same way, e.g ESB fronting a Oracle database access?
I don't think you'll find much in this strict sense. ESB is basically made for transferring messages between enterprise services. A DB is not an enterprise service. In this case you'd need processing beans that handle your specific need.
What you could do, however, is to put a service in front of your DB. This service could then expose the DB in some format. For example, SOAP over JMS seems fitted to your use case. SOAP can handle security and access, JMS gives you asynchrousness and exactly-once delivery guarantee, which will be needed if working with a DB. ESB frameworks can handle JMS and SOAP very well.
So instead of looking for a "ESB backed database", as you called it, this service may be something that you can look for on the market, and then you can route client services by using an ESB, which makes sense.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
I have to design an application which gets requests from multiple sources like Web service (can be SOAP or REST), online system, Message Queue or some batch job. Application needs to interface with 2 more applications for getting results. I understand that this can be done using microservices. This application needs to be built in Java. I am looking for some framework which can help me with accepting input from multiple sources as mentioned above.
If you want to build a lightweight simple layer (single app) to cater all these requirements, I would recommend using Apache Camel. This single app can listen to rest/soap requests, read from file system, JMS store, database etc. You can even embed it into another application and have all sorts of integration with different data source and excellent and easy to configure routing and transformation engine. Plus the documentation and community is awesome.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I'm going to create a desktop application (Swing) using the MVC. It will be chat and i have some questions. Which classes should be located on client? (View - its logical) Model? Controller? or both classes should be on the server side?
And which classes have to process my database?
If you are planning to have server-client and database access, this sounds like a typical 3-tier distributed system.
Database - represented as DBMS and located potentially on a separate machine. This should provide easy API for queries and updates from the server.
Server - this is where Model is located, again potentially on a different machine than database. Server however has means of working with the database, ideally via the aforementioned API.
Client - contains View and Controller. View is essentially the UI aspect of the Model located on the server. Controller processes user interaction and sends to the server in the processed (clean) form that the server can understand. This is done to reduce server load. The client has no means of accessing the database directly.
If it's all the same to you, I'd recommend to have a look at JavaFX, its MVC is much easier to implement and just plain simple to work with
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
Hello,
I have read some where we can publish web-services directly from databases i.e applications can make http calls to databases directly and retrieve data from web-services. Is it really possible... i have searched in internet but haven't found anything much useful...
I have a requirement that i want to connect Salesforce to oracle or PostgreSQL databases and has to retriew data.Initially i planned like creating a web-service in java to connect to dtabase and retriew data and sending that data to salesforce as web-service response... But have thinking is it possible to create web-services on databases it self so that external applications can connect to databases using http calls.. Because in Salesforce there is no option to connect to external databases directly..
I have searched a lot but haven't find any strong point's..hoping some one could guide me on this
Yes. However, databases that support webservices directly are (AFAIK) all NOSQL type solutions. For example, apache couchdb has a wiki on HTTP_database_API and it documents
List Databases
PUT (Create New Database)
DELETE
And other operations. Another example is OrientDB the wikipedia entry states that it is Web ready: supports natively HTTP, RESTful protocol and JSON without use 3rd party libraries and components.
Alternatively, you might implement your own middle-ware layer of web-services to connect to any other database.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I've never used SOAP or EJB. I read about SOAP and can't grasp one (maybe the main) point.
Question: Why should one use remote interfaces instead of simple request/responce scheme?
My considerations: SOAP allows us to invoke methods of remote services. It uses XML. But why it's better than just use SOA (service oriented approach) and send an JSON request -> get JSON response. I do so in my application with help of WebSockets and JSON. Moreover, SOAP is slow, seems it is slower than approach that I need.
I suppose the advantage of the remote interface is that you wouldn't have to parse any XML. When you receive your reply from a remote interface an object is constructed that you are able to use without any further processing. However SOAP seems to be a more popular method currently as you are not restricted to a particular environment. For instance you have to use java on the client to use the remote interface but with SOAP any client can accept and process the XML
The reason for this is SOAP takes a contract-first approach. This also allows us to build classes from these contracts so we have classes that can be built by a WSDL. This is very useful because it means we don't have to build classes representing the web service endpoint, however, if the endpoints signature changes we need to update our associated generated WSDL classes.
SOAP, in my humble opinion, is much more useful for say .NET or Java because of the classes that can be generated from it and the help your IDE can bring by instantly allowing you to access these classes. When I've used php, I always found it felt like SOAP wasn't quite as easy to work with as REST because of having to build up XML responses when all you want to actually send is "something=true".
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I have two Java EE web apps that are going to be published on the same physical server, but on different network addresses.
APP A: Listens to a port on a public IP address and makes synchronous invocations to app B if necessary.
APP B: Listens to a port on a private IP address and makes synchronous invocations to app A if necessary.
For connecting APP A with APP B, I am considering the following alternatives.
RMI
Message Queue
Lightweight ESB
Please tell me if you see any clear advantage supported by facts on any of them, or if there's another technology I should consider.
Every integration method has its advantages and disadvantages, and its really hard to propose one based only on what you have provided, but here is some hints:
Quick and Easy: if you don't mind high coupling, and major changes in the applications are not expected (like DB engine, or replacing on with non-Java system), you can go with RMI or even DB Procedure calls.
Changes, Extendability and Scalability: if the applications are expected to be changing more than rarely -and they tend to do-, ESBs or Message Queues would be great, since they would produce a loosely coupled architecture. This would also make room for extendability (like if you would have a new application C, that would need to invoke A or/and B)
HTTP Availability: If HTTP communication is available between applications, Web Services is an excellent integration method.
Developers Knowledge: What technologies you/the team are familiar with.
These are actually small hints, if you wish to go further in your research, I strongly recommend reading Enterprise Integration Patterns the book.