I am going to make a small trade management system. I want to make a independent database service to which all the other client connect. The database will be MYSQL and I will be using Java for making the service. The client can either be a Web Application or a desktop application using Java Swing (has not decided yet). There will be another layer sit between the client and the database service to handle the business logic (I call it trade service).
The architecture is something like: Client -> Trade Service -> Database Service.
My questions is that what client/service communication technology is the best suitable one for client->Trade Service and the best suitable one for Trade service -> Database.
Shall I make it s RESTful service? SOAP? Using RPC? Or any other technologies?
Many thanks for your help. Any idea or suggestions are welcome.
Take a look at RabbitMQ, A pool messaging service
http://www.rabbitmq.com/
It's Robust, flexible, fast and scalable and you can use it to communicate in Java, PHP, or whatever technologies ou want.
Shall I make it s RESTful service? SOAP? Using RPC?
These are all very similar approaches in that they are over HTTP so - assuming that's what you want; I would recommend using RESTful. You'll have lot's of examples to work with and it will allow you flexibility in the future to do things like switching out the UI layer for a smart phone app or desktop app.
Regardless of what model you pick you should understand how it works first and build in things like security and guidelines early. Do your homework now. Trying to change the middle layer of a design like this is a pain.
There is no blanket answer to your question, there are instead options based on your skill set. Do you conceptually understand the HTTP spec completely and be able to extend it to REST, that works very closely with HTTP (common creation ancestor). Do you better understand the traditional method invocation of SOAP? Are you tied in your ecosystem to a specific language, as this can impact which tools you choose from.
If you were paying me to write a service based on the simple requirements you have given (which is nearly impossible), I would create a domain driven design service (your business layer) with a RESTful interface and Spring JDBC for data access. That is me, and what I work in most often. My partner in crime at work would probably choose SOAP and Hibernate.
I think what you're taking about is Queues, and I'm guessing you need a managed service for that. Queues can be the glue between your micro-services. Some of the vendors I know which have Queue as a Service are :
CloudBoost.io : https://www.cloudboost.io
Check out https://tutorials.cloudboost.io/en/queues/basicqueues for documentation.
Iron.io : https://www.iron.io
P.S : I work at CloudBoost
Related
I am planning to design such an architecture for my website as shown in picture above. I am building a core platform in Java that do the communication with DB and other high processing tasks and modules can hook up with the core by means of defined interfaces.
Modules could be anything like, front-end website, email box, admin consoles etc. and could be built on any technology like PHP, Java, ruby on rails etc.
Now tell me which communication protocol should I use for communication between modules and core. Protocol must be something that majority of languages understand and can be process easily in both way communication.
And if somebody find any flaws with such an architecture then kindly suggest a better one that provide great extensibility and flexibility.
I would use HTTP, exposing a REST API on the Core, such as Thilo suggested.
The complexity lies on the trade-offs between RPC (procedural model) of traditional webservices, and the Resource Model, which fits better when using http requests (verbs GET, POST, PUT and DELETE on URI's, complemented with some headers and a body).
Yet, this makes a soft, easy to maitain and portable ditribution. Every single client module may be built on a whole different technology, which allows you to use "the best tool for the job".
Not to mention HTTP advantages for caching, rewriting, load-balancing, ssl, etc.
So basically this is a SOA-like architekture. JavaEE and EJB (3+) or the Spring frameworks come to mind immediately.
The components (your "modules") are usually coupled via SOAP services with an optional Enterprise Service Bus (ESB) between frontend, backend and the composite services.
Whether this is a good match for your case or simply oversized... noone but you can say...
I have a service Stock/Products(REST API) and a service Orders (RPC API). The Orders service will use some data from Stock/Products.
Orders will be used from a GUI Client.
I see two options for integrating:
use Stock/Products from the Orders service itself (integrate in the server)
use Stock/Products from the GUI client.(integrate in the client/UI)
Which would be a better approach?
I tend to choose (2) because i don't see why I would 'tunnel' the REST API through the RPC API.
I think you should prefer integration in the server, because encapsulation is better that way. Your chief objective should be to make life as easy for clients as possible.
The client should only need to know that they want their orders. Let the server handle the details of assembling products.
You have a perfect example in Amazon.com. They let you get what you need with a single request, but lots of services participate in making it so.
As we are in the beginning phases of rejuvenating our application in to SOA design I have some questions that I can not get a clear answer/picture on.
I have been doing a lot of reading, mostly around books from Thomas Erl and following that design pattern of understanding what Task Services, Entity Services and Utility Services are.
What I am stumbling on is the whole DAL concept of how that would look. So this is more of a verification of understanding or a clarification so as to help make the best approach for our platform.
So background. We currently have several web based e-commerce applications that have been pretty much been built in silos and are again pretty much a copy of each other. We have supporting applications such as Daemons and misc web services out there. Many of these applications are older then 5 years and are build on only technology (Model 1). All of our applications are centered around conducting auction sales. So during a sale event we will be taking bids from users, determine who is winning and display that information back. Each sale event has a set amount of time that they will be available to the users.
The company is moving towards a SOA solution as a lot of things we end up doing can be shared across not only our group but across other groups.
So what I understand on the DAL is that it in itself is a service which will sit on top of Data, in this case different Databases - MSSQL, ORACLE, MSSQL. Each of these databases have different schema's (Oracle) etc.
So the services (Task, Entity, Utility and Presentation Tier if needed) will make calls to the DAL to retrieve data. It is the responsibility of the DAL to know, from the contents of the message to determine what it needs to do in order to fulfill the request.
So for example, we have a Security Service candidate. This service needs to authenticate with LDAP and to authorize from the data that is stored for that given application.
The thought here is that a Utility service will be created to wrap up all the operations required to communicate with LDAP and that the Security Service will call upon the Utility Service and to the DAL to fetch the authorization data. The DAL then has the responsibility to go to the correct database/schema to retrieve the information. The information will be in XML format (standard SOA communication).
So, am I on the right track here? Have others done similar things or not? What other things do I need to consider (Currently getting the statistics on how many bids we take in an hour - on average).
Should each service have its own DAL - for example should the Security Service have the DAL as part of the service or should DAL be a shared service in which all services can use?
In your case, the approach to use for a full SOA based deployment would be to use an ESB, Identity provider and a data services solution.
To break it down, the DAL should be implemented using data services, in this way, this service will be a globally accessibly service in a language neutral way, and will support re-use and loose coupling. So all your data access logic can be implemented as web service operations in a data service.
So for the authentication and authorization management, in the SOA world, there's a standard called XACML, which is used for fine grained authorization management. So what you will need is an XACML server, who would authorize the user according to a specific criteria, where this should also have the ability to authenticate with LDAP.
Then your "Security Service" will be implemented in a service at the ESB, where that service will query the identity provider for authentication/authorization and according it's response, it will call the appropriate operations in the data service, with suitable parameters to fetch the data, and return it to the user.
The above scenarios can be implemented using WSO2 Data Services Server, WSO2 Identity Server and WSO2 ESB respectively, which are open source products, and can be freely used and found here.
i once worked with (developing) an soa project that used a "data service". it was some time ago, and i was only involved marginally, but my recollection was that it ended up being too complicated and slow.
in particular we had no real need for a data service - it would have made more sense to have placed the same abstractions in a library layer, which would have given better efficiency and no real loss of functionality (for our particular needs). this was exacerbated by the fact that the data tended to be requested in many small "chunks".
i guess it comes down to the trade-offs involved in the implementation. in our case, with a relatively closed system and a single underlying database technology, we could have easily exploited the support for distributed access that the database provided; instead we ended up duplicating this in a slower, more general, message bus, which added nothing except complexity. but i can easily imagine different cases where access to data is more "distant".
How you have to use SOA for your design is depends on the its requirements.
In generally you can write coarse grain services and expose them as web services. In your case you can write some services which calls the databases and produce the results. In this case authorization logic can also be written with the service logic.
The other approach is to use an ESB or BPEL engine to write the integration logic and expose the integrated service as a web service. In this case you can use some data services to expose data base data in xml format and integrate them. You can use services for different sachems and call the correct service with the request data. And the authorization logic can also be added to service integration logic.
Security aspects such as authentication, confidentiality, integrity is considered as non functional requirements and hence can be engaged to any service without writing an explicit security service.
Following articles describes such sample possible integration of services as mentioned in the second approach.
http://wso2.org/library/articles/2011/05/integrate-business-rules-bpel
http://wso2.org/library/articles/2011/06/securing-web-service-integration
We are developing a service for our portal / web client developed using JSF . My advice was to expose the service as REST but another team member said to go with RMI implementation since its easier to deal in java object from development and testing point of view.
My argument was development and testing efforts with be pretty much the same but we will get all the goodness of REST web services.
FYI : We already have REST setup so there is no extra cost in framework support. This services are exposed for our smartphone client who uses REST api.
At the end our Manager decided to go with RMI way but I still think REST would be smarter way.
What would be your choice REST or RMI?
Note : Nothing against my team member or Manager just trying to learn here.
If there are firewalls between your client and server, it is likely that RMI traffic might be blocked. HTTP traffic is open on most firewalls and REST should have no problem getting through.
The biggest argument against RMI and for REST/SOAP etc is that the client does not have to be Java.
If your front-end could change down the road from JSF to ASP, then you'll be in some trouble.
Other than that, RMI is the way to go. An even better way to go is EJB ( which is a layer on top of RMI ) with additional advantages -- lots of vendors already implement the EJB spec, you get the advantages of object pooling, transaction management etc.
Is the client in Java, use RMI. But that is to simple thought. As it is only a point to point protocol.
REST as a paradigm is interesting if you have e.g. many reads and like to use HTTP technologies for caching etc. The next thing is you likely can easy implement "paging cursors" so you send data as a small page and add info how to retrieve the next page.
Your question basically is formulated as if it is a technology question. Which is the wrong approach. You should not bother about technology but about system architecture. The whole software system, its abilities, its performance, its scaling, its configuration and its maintenance is completely different depending on your usage of RMI or REST.
For now we have very heavyweight frontend (frontend+backend in one application actually). Frontend contains all the logic: UI, business logic, persistence logic and so on. It's very complicated and hard to maintain, because of some platform problems (it's written in PHP) like absence of connection pooling, for example.
So I came up with an idea to separate frontend and backend. Backend can be written in some more convinient platform (we plan to use Java), and frontend can continue use PHP.
I think UI logic is all frontend should do. And some limitations should be applied to codebase which is executed here:
No direct database calls. DB calls are hard to scale and hard to provide SLA.
Nonblocking integration plotocol to backend. If frontend asks something to backend, frontend should be able not to block on this request. It can help us in two ways:
a. we can send parallel requests to backend (parallelize I/O);
b. we can provide timeout for requests (SLA). Sometimes it's better to fail quickly and do not block client.
So, considering all above, I think the best architecture for frontend (in my case, i'm not propagate silver bullet) is UI logic which is communicates only to REST/SOAP backend in nonblocking way. What do you think about this stuff?
You may want to look into node.js for your frontend - it's new, but it has a really cool asynchronous (ie nonblocking) architecture. Does mean leaving PHP behind, but if your doing a major rewrite anyway that's not going to add too much new work.
Sounds fine to me, and you have the option of sucking info out of the (java?) BL both at the server-side and client-side (via AJAX).
I think UI logic is all frontend
should do.
Yep - you're definately thinking straight :)
You can go with the below architecture.
You can go with any of the JS framework like Angular 4 or ReactJS as both has server side rendering. This will work for Single/Multiple Application as well.
Define the RestFul API with PHP where all business logics will be there. The API should be hosted in different server.
To make API secured you can have OAuth authentication.
If you use PHP, I suggest to use stored procedure instead of hard coded SQL queries or any ORM.