Evenin' good people!
I'm creating a virtual whiteboard application for my third year project at university. The system uses a Flex front-end and a Spring/BlazeDS back-end. I'd say that I'm pretty new to BlazeDS and to Flex, so apologies if anything I say doesn't make a lot of sense.
I'm attempting to implement a (reasonably) secure server push from Spring/BlazeDS to the Flex application, based on groups (whiteboards).
I've discovered that BlazeDS offers a publish/subscribe messaging architecure which includes support for sub-groups. However, I can't find a way of restricting access to particular (password-protected) groups, available only to users pre-authenticated with the system. my system is also using a custom log-in process, mediated through Flex RPC calls.
Additionally, I've considered writing a custom messaging-adapter; however getting this to #autowire with the rest of my project (and a custom authentication system) has proven difficult, and so far I've had little success.
All-in-all, I'm at a little bit of a loss for how to continue. Any help would be greatly appreciated.
If I understand your problem currectly you are trying to implement ' Authorization based subscriptions'. The user can subscribe to a group only if he is authorized to so?
If so, Flex has a concept of 'subtopics' the client subscribes on to a destination with this subtopic. This subscription can be manually managed by extending Adapters in flex. override a couple of methods to do so.
when the client requests for subscribe on this 'subtopic', handle the subscription in the adapter, maintain a list of subscriptions, also there is an overriden method in the same adapter to handle the push of the messages, you can use it to find the authorization of the user and push messages accordingly. (these methods are not invoked by you directly) thre are classes in blazeds to construct the message objects and pushe it to the client i think it is AsyncMessage use this to push.
Its been a long time since I worked on this, I hope you got some direction.
Related
I'm starting to work with NestJS, a Javascript framework for building RESTful api's.
The framework encourages you to work with multilayered architecture, separating controllers, services and repositories.
In this project of mine, I have a RESTful api that talks to my website, and I'm currently in the need of using websockets for several reasons.
The general behavior of a module that will use the websocket protocol (in my app) is:
client makes http request with a message -> backend validates -> backend broadcasts the message through websockets.
Much like a chat application.
The problem is that I'm having a hard time figuring out where is the best place to put these broadcast calls. It seems like every layer is the wrong place.
I won't even consider the repository layer. Talking strictly about whether should I choose the controller or the service, they both seem wrong.
I don't want to send websocket messages in the same place where I handle HTTP requests, and I sure don't want to send them in the same place were I deal with business rules.
I've come to an approach, but I'm not sure if it's necessary to do it. I'm using Redis as caching mechanism, and as a store to Socket.io, so that I can horizontally scale my app and consistently send broadcast messages through sockets. Redis also has a Pub/Sub feature within it, and an awesome notification system called "keyspace notifications" that will publish messages to channels depending on the action performed in the cache memory store. Long story short, HTTP requests changes resources in the backend, these changes are reflected in my Redis cache and, with a (to-be) well crafted key design system, I can listen to the modifications in the cache from another, separate, module and fire the necessary broadcasts.
An illustration of the structure:
Actually, using the correct keywords I found this article in which the author is doing something similar to what I'm proposing here.
I am a newbie in Microservices, having theoretical knowledge. I want to make a small application in Microservices. Can anyone please help me with the idea of how to implement microservices?
Thanks in Advance!!
You can create something like a currency conversion app with three microservices like these:
Limit service;
Exchange service;
Currency conversion service.
Limit service and currency conversion service can communicate with the database for retrieving the values of the limits and currencies conversion.
For more info check github.com/in28minutes and look after a microservice repository.
No matter how perfect the code of your microservice is, you may face issues with support and development if the microservice architecture doesn’t work according to certain
rules.
The following rules can help you with microservices a lot:
You have to do everything by yourself because you do not have any Rails and architecture out of the box that can be started by one command. Your microservice should load libraries, establish client connections, and be able to release resources if it stops working for any reason.
It means that being in the microservice folder and having made the 'ruby server.rb' command (a file for starting a microservice) we should make the microservice do the following:
Load used gems, vendor libraries (if used), and our own libraries
Use the configuration (depend on the environment) for adapters or classes of client connections
Establish client connections (permanent connections are meant here). As your microservice should be ready for any shutdowns, you should take care of closing these client connections at such moments. EventMachine and its callback mechanism helps a lot with this.
After that your microservice should be loaded and ready for work.
Incapsulate your communication with the services into abstractly named adapters. We name these adapters based on their role (PubSub, SMSMessenger, Mailer, etc.). This way, we can always change the inner implementation of these adapters by replacing the service if the names of our classes are service agnostic.
For example, we almost always use Redis in our application from the very beginning, thus it is also possible to use it as a message bus, so that we don’t have to integrate any other services. However, with the application growth we should think about solutions like RabbitMQ which are more appropriate for cases like ours.
If your code is designed in such a way that your classes are coupled with each other, do it according to the dependency inversion principle. This will help your code to avoid issues with lib booting.
Learn more here
You can try splitting an existing Monolithic application to gain perspective on microservice architecture.
I wrote this article, which talks about splitting a Django App into microservices. Hope it helps.
I guess this is not a specific question, but getting ideas on how to.
We have a Flex - Spring - JMS - Hibernate webapp. Our requirement is to send automatic emails when some event occurs (new user registered, user performed an import successfully). We will have the Email addressess, content, Subject, etc in the DB. We can have the Mail Server settings hardcoded (or in the db). I would like to have this as a separate service for reusabulity. I would like to get your inputs on how to achieve this and also provide some optimal solutions on what would be the best way. Do I use JMS for this or Spring's Java Mail Sender. Which is more efficient and the latest.
Hope my question isn't too vague. Your inputs are appreciated as always :)
Thanks
Harry
Here are few low-hanging choices you have (from best to worst):
Spring Email support
The Spring Framework provides a helpful utility library for sending email that shields the user from the specifics of the underlying mailing system and is responsible for low level resource handling on behalf of the client.
This is the simplest approach (not counting coding to raw JavaMail API). If you need to just send that e-mail, you don't need nothing more. You can esaily inject JavaMailSender wherever you need it.
Email support in spring-integration
Spring Integration provides support for outbound email with the MailSendingMessageHandler. It delegates to a configured instance of Spring's JavaMailSender [...]
This solutions is built on top of 1. If you need a reusable service with enterprise integration patterns bundled (like filtering, routing, enhancing, etc.) and great flexibility. If your application does a lot of integration, this might be a smart choice but is a bit more heavyweight when it comes to maintenance.
SMTPAppender in logback
The SMTPAppender accumulates logging events [...] and sends the contents [...] in an email after a user-specified event occurs. SMTP email transmission (sending) is performed asynchronously.
This Logback appender is typically used to send an e-mail yo support/administrator when an ERROR occurs, containing error event itself and few previous events. But with a little bit of configuration you can easily use to it catch specific events in your application (triggered by logging statements) and send messages. However it will be a bit cumbersome and not flexible enough.
Within salesforce, we're envisioning someone clicking on a quote button on an Account object record and having that pass a number of fields information to 1 of two systems. One system would be a web application. The other, a windows application. I was thinking it would be a JavaScript call to the systems, but I'm not sure. What are some of my potential options? How would you guys go about doing this?
Thanks and sorry it's so broad.
One thing to look into is Outbound Messaging in Salesforce. Outbound messages are triggered as part of a workflow rule. I think you'll find outbound messaging to be a much more robust solution than an AJAX call to a web service. For instance, if your web service cannot process an incoming request, the outbound message will queue up on the Salesforce side. Then Salesforce will attempt to resend the message at regular intervals.
Outbound messaging is a great approach and I'd choose that direction for single SObject integrations when possible. However, if you need to pass any form of related list (master-detail/lookup relationship) you'll need to tackle this another way since outbound messaging only fires on a single object at a time. You can configure multiple outbound messages to get around this but this can quickly become unmanageable. JavaScript is certainly doable but using SOAP or REST from within Apex is more sturdy and secure.
I prefer REST/HTTP since Apex has had trouble consuming complex WSDL from external systems. In fact Apex is not able to consume the Force.com API or the Metadata API for size reasons. But the built-in HTTPRequest/HTTPResponse classes from Apex using either the built-in XMLStream/DOM or System.JSON classes to parse results works really well imo.
I am planning a new application and have been experimenting with GWT as a possible frontend. The design question I am facing is this.
Should I use
Option A: GWT-RPC and build the app quickly
Option B: Build a REST backend using Spring MVC 3.0 with all the great #Controller, #Service, #Repository annotations and build a client side library to talk to the backend using the GWT overlay features and the GWT Request builder?
I am interested in all the pros and cons and people experiences with this type of design?
Ask yourself the question: "Will I need to reuse the server-side interface with a non-GWT front-end?"
If the answer is "no, I'll just have a GWT client": You can use GWT-RPC, and take advantage of the fact that you can use your Java objects both on the server and the client-side. This can also make the communication a bit more efficient, at least when used with <inherits name="com.google.gwt.user.RemoteServiceObfuscateTypeNames" />, which shortens the type names to small numeric values. You'll also get the advantage of better error handling (using Exceptions), type safety, etc.
If the answer is "yes, I'll make my service accessible for multiple kinds of front-ends": You can use REST with JSON (or XML), which can also be understood by non-GWT clients. In addition to switching clients, this would also allow you to switch to a different server implementation (maybe non-Java) in the future more easily. The disadvantage is, that you'll probably have to write wrappers (JavaScript Overlay Types) or transformation code on the GWT client side to build nice Java objects from the JSON objects. You'll have to be especially careful when you deploy a new version of the service, which brings us back to the lack of type safety.
The third option of course would be to build both. I'd choose this option, if the public REST interface should be different from the GWT-RPC interface anyway - maybe providing just a subset of easy to use services.
You can do both if use also use the RestyGWT project. It will make calling REST based JSON resources as easy as using GWT-RPC. Plus you can typically reuse the same request response DTOs from the server side on the client side.
We ran into the same issue when we created the Spiffy UI Framework. We chose REST and I would never go back. I'd even say GWT-RPC is a GWT Anti-pattern.
REST is a good idea even if you never intend to expose your REST endpoints. Creating a REST API will make your UI faster, your API better, and your entire application more maintainable.
I would say build a REST backend. In my last project we started by developing using GWT-RPC for the first few months, we wanted fast bootstrapping. Later on, when we needed the REST API, it was so expensive to do the refactoring we ended up with two backend APIs (REST and RPC)
If you build a proper REST backend, and a deserialization infra on the client side (to transform the json\xml to GWT Java objects) then the benefit of the RPC is almost nothing.
Another sometimes forgotten advantage of the REST approach is that it's more natural to the browser running the client, RPC is a propitiatory protocol, where all the requests are using POST. You can benefit from client side caching when reading resources in the standard way.
Answering ams comments:
Regarding the RPC protocol, last time I "sniffed" it using firebug it didn't look like json, so I don't know about that. Though, even if it is json based, it still uses only the HTTP POST method to communicate with the server, so my point here about caching is still valid, the browser won't cache POST requests.
Regarding the retrospective and what could have done better, writing the RPC service in a resource oriented architecture could lead later to easier porting to REST. remember that in REST one usually exposes resources with the basic CRUD operations, if you focus on that approach when writing the RPC service then you should be fine.
The REST architectural style promotes inspectable messages (which aids debugging and security), API evolution, multiple platforms, simple interfaces, failure recovery, high scalability, and (optionally) extensible systems via code on demand. It trades per-interaction performance for overall network efficiency. It reduces the server's control over consistent application behavior.
The "RPC style" (as we speak of it in opposition to REST) promotes platform uniformity, interface variability, code generation (and thereby the ability to pretend the network doesn't exist, but see the Fallacies), and customized interactions. It trades overall network efficiency for high per-interaction performance. It increases the server's control over consistent application behavior.
If your application desires the former qualities, use the REST style. If it desires the latter, use the RPC style.
If you're planning on using using Hibernate/JPA on the server-side and sending the resulting POJO's with relational data in them to the client (ie. an Employee object with a collection of Phones), definitely go with the REST implementation.
I started my GWT project a month ago using GWT RPC. All was well until I tried to serialize an object from the underlying db with a One-To-Many relationship in it. And got the dreaded:
com.google.gwt.user.client.rpc.SerializationException: Type 'org.hibernate.collection.PersistentList' was not included in the set of types which can be serialized by this SerializationPolicy
If you encounter this and want to stay with GWT RPC you will have to use something like:
GWT Request Factory (www.gwtproject.org/doc/latest/DevGuideRequestFactory.html) - which forces you to write 3+ classes/interfaces per POJO you want to share with the client. OUCH!
Gilead (sourceforge.net/projects/gilead/) - which appears to a dead project.
I'm now using RestyGWT. The switch was fairly painless and my POJO's serialize without issue.
I would say that this depends on the scope of your total application. If your backend should be used by other clients, needs to be extendable etc. then create a separate module using REST. If the backend is to be used by only this client, then go for the GWT-RPC solution.