Communicating with ACR1255U-J1 from PC and sending ISO 14443 - java

I want to communicate with an NT3H211 tag from nxp. it supports ISO 14443.
I'm not sure how to do this in java using the ACR1255U-J1. There seems to be some drivers on the ACS website but it is not clear to me.
see page 45 of http://www.nxp.com/docs/en/data-sheet/NT3H2111_2211.pdf
How can I send e.g. WUPA and GET_VERSION via the reader ACR1255U-J1 from windows?
Are there more DEV friendly smartcard readers out there?

How can I send e.g. WUPA and GET_VERSION via the reader ACR1255U-J1 from windows?
You would need to use/develop an application using the PCSC command interface on windows. This works through the CCID standard driver provided by windows to interface with the ACR1255U-J1 over USB. There's open source Java implementations online like this one that will allow you to start getting familiar.
Are there more DEV friendly smartcard readers out there?
The ACR1255U-J1 is actually one of the more dev friendly readers on the market. The problem is that the superset of APIs exposed can be daunting to unfamiliar developers. Flomio offers a simpler SDK for mobile devices and web clients to get devs started quickly. It's based on a subset of APIs focused on just scanning a tag. More complex exchanges are then concealed behind a second layer of APIs. This reduces the learning curve and often devs are up and running in a couple hours. You can check this Forum for further details on how this goes.

Related

Converting desktop application into server + browser application

I am relatively new to web development, but I have some C++/Java experience. I have got the following conversion to do:
Current:
Desktop Application (Automation Software) developed in C# that communicates with remote PLC (Controller that overlooks different sensors in realtime) using TCP Sockets over the Web.
My Idea:
Convert the application into a server side software that will still communicate with the PLC over TCP/Socket. And use a browser to operate it, so the remote site can be monitored and controlled from any computer in our Intranet (possibly Tablets in the future).
Motive for doing it:
We had a computer fault which left the operators without control.
The new app:
I am planning on writing the server app using Java and OOP (so far no problem). And use HTML/CSS/Javascript for the WebApp and AJAX to update the page.
But I am still lost at how can I transport all this data between them in a proper and decent manner. I have read about SOAP and JSON in this Post. Although, I am not sure if I need to use them at all, is it a good solution to use either JSON or SOAP? Or is there any other solution that you may recommend?
Cheers,
Leo
If you consider skipping the development work to convert your app into a server-side software and just go for a third party solution, I suggest you take a look to Thinfinity VirtualUI.
"...offers a GUI remoting solution for in-house Windows desktop
developments, allowing them to be delivered as Windows/HTML5 dual-platform applications
simply by adding one line of code.
These Windows applications can keep their standard desktop environment behavior and,
alternatively, be accessed remotely from any modern web browser in a multi-user,
multi-instance fashion when hosted on a Thinfinity VirtualUI Server environment."
https://www.cybelesoft.com/docs/thinfinity_virtualui_whitepaper.pdf
SOAP is for defining public APIs that are published on the internet for other people to use, which does not seem like your use case. It is not particularly awesome to have to deal with it from inside a browser either, although there are javascript SOAP-client libraries. There is also going to be a fair bit more overhead on the server side parsing and validating XML than de/serializing between JSON and POJOs.
JSON is much easier to deal with in a browser, being natively understood and all that. Everything you need is built into the core of jQuery, no dependence on plugins that may have unknown levels of future support.

Kaazing vs jWebsocket

Can somebody please compare these two websocket servers. I have to select one of them; I need an expert opinion due to newbie in multiplayer "online" gaming. I would probably have the flash client. What challenges I could face using one over other.
thanks in advance.
Full disclosure: I work for Kaazing and I have not used jWebSocket myself.
A couple of quick points:
0) Production vs. Beta
Kaazing is production-quality software. The download link on the jWebSocket web page points me to a beta version of the product.
1) Client Technologies
Kaazing provides WebSocket libraries for multiple client technologies (JavaScript, Java, .NET/Silverlight, and Flash), It looks like jWebSocket provides JavaScript and Java. You mention you would need a Flash client and AFAIK only Kaazing provides that. jWebSocket uses Flash for emulation (see the next point).
Note: Kaazing now provides AngularJS, ReactJS, Objective-C (iOS), Xamarin (.NET with support for iOS and Android), Java, .NET, and Android clients. However support for SilverLight and Flash have been deprecated.
2) Emulation (for browsers that do not support WebSocket)
jWebSocket requires Flash, Kaazing does not.
Note that Flash emulation for secure WebSocket (wss://) requires you to open a separate port for the Flash x-domain policy file. In many enterprises this is a non-starter.
3) Protocol Support
Kaazing offers a wide range of higher-level protocols on top of WebSocket: JMS (can run against any back-end JMS message broker), STOMP, AMQP, XMPP, etc. I don't know what jWebSocket does in this space.
4) Enterprise Deployment
It is easy to configure the Kaazing WebSocket Gateway in conjunction with existing Directory services (LDAP). It supports Single Sign-On, and the gateway can easily be clustered for HA purposes (again, not quite sure what jWebSocket does here.)
Please take a look at the documentation for these features:
Security configuration:
Using the Gateway to Support High Availability
Secure Network Traffic with the Gateway
5) Open Source
jWebSocket is open source, Kaazing has both an open source Community Edition and an Enterprise Edition.
Hope this helps for now!
I am a jWebSocket developer, we are currently working in the first production version of jWebSocket, I will just mention some advantages of jWebSocket:
- Multiple clients ( JavaScript, C#, Java OS, BlackBerry, Android, GWT(In process), and some others ).
- Multiple WebSocket engines, just switch and run in the configuration, among them (Grizzly-GlassFish, Tomcat, TCP, NIO...) in order to become jWebSocket more widely used and make applications easier to be migrated.
- NFC and SmartCards, Arduino and other technologies.
- A very variated set of Demos in the client side (Games, Chat, sms, WebSocket-Captcha, Sencha, Jquery & jQuery Mobile plugIns, Arduino, Smartcard, SessionStorage, SSH-Remote Shell Control RT in the web, a Ping Pong Game demo, Channels to create full client side applications without need a server side plug-ins, etc... )
We have been working during a long time in a new Documentation, a new Web Site and a new Production release of jWebSocket for our community, jWebSocket is a project created by people from all the world who dedicate their free time to contribute and create a really usable product to be used by all the opensource community. We are trying to give our best to the community.
I wouldn't establish a comparison between Kaazing and jWebSocket, they both have different communities, goals and LICENSES.
For a gaming platform you might want to check out http://www.pubnub.com/. I met their CTO at a developer conference and for your stated purpose, you might just win big with not having to manage the infrastructure on your own. Check out their http://www.pubnub.com/customers/showcase for details on who is using their infrastructure and for what purpose.
For me, the main point is Kaazing has a proprietary license and it's payed. jWebSocket is LGPL and free. If you are developing an application with an ROI that allows you to pay for a service like Kazzing, I think it is a good option (like pubnub.com and pusher.com), but if you want to build a complete solution and host it or you want to contribute with OS community to create a new websocket alternative, jWebSocket is an excellent option.
There are two things I would add to Peter's comment, one is that Kaazing's emulation solution exposes identical APIs to the native WebSocket APIs, so you only have to learn WebSocket not some other proprietary API. You can check out the demos and the doc that Peter referred to for more information.
Secondly, Kaazing just announced the availability of Kaazing WebSocket Gateway AMIs on Amazon EC2 - http://kaazing.com/cloud
Best,
Jonas
I've been working with jWebSockets for the past 3 months or so, and this is the first I hear of Kaazing.
I will describe how I feel about jWebSocket so far to the best of my ability in the hope that it will help.
Setting up the developing environment and getting started wasn't easy but developing using it is rather comfortable. The entire system makes sense and it is quite easy to understand. You program with Java on the server side and js on the client using json based tokens, it makes it very easy to send and receive data.
It is however very lacking in support. There are a lot of missing documentation and the support forum is nearly dead. There is payed support from the developers but I've never tried it.
There are a lot of open source demos that you can use to understand and get started. Most of them were working smoothly. Something I cannot say about kaazing after a brief visit to their demo site.
In the few months I've been working with jWebSocket I've yet to encounter a single bug, The system works smoothly and my only disappointment is the lack of support and documentation.
If you are looking for a pure open source project, look at the Atmosphere Framework. License is Apache 2.
-- Jeanfrancois (creator of Atmosphere)
jWebSocket is a good framework and support almost all servers. It has support of jetty too. Only problem with jWebSocket is slow development and zero support. Websocket specification are changing very rapidly and jWebSocket releases are very slow. I would prefer to wait and watch jWebSocket framework for some time.

A good Java wrapper for TAPI 2?

Does anyone know of a good JNI/Java wrapper for TAPI 2?
I need to interact with the Avaya phones on the desks of my users for a CRM web application (based on GWT), and all computers have a TAPI 2 driver already installed (no TAPI 3 driver is available). Unfortunately the phone server does not produce events for calls-in-progress in a centralised form, or provide an API for initiating calls centrally.
I plan to use a signed Java Applet in the background of the web app to connect via TAPI and interact with the GWT client code via GWTAI.
I found the JTAPI implementations XTAPI and GJTAPI - but they are convoluted (due to the big differences between JTAPI and TAPI), buggy, and don't implement all TAPI functionality (e.g. XTAPI only provides 2 lines of call info of the dozen available).
Helen Warn's C# Wrapper provides a fantastic wrapper for TAPI 2 in C#, that does exactly what I want, providing direct access to the simple TAPI 2 interface. The only problem is that embedding an ActiveX control in a web page is off-limits as we really don't want to be locked into IE!
So it looks like I'm going to have to port Helen Warn's wrapper to Java using JNI? (not a trivial task).
Any other ideas?
Despite similar-looking names, TAPI and JTAPI are two completely different APIs. With regards to Avaya, TAPI is used to control Avaya IP Office series PBX and softphone applications running off Communication Manager (formerly Definity) series PBX. JTAPI is, in fact, a Java implementation of Novell's TSAPI protocol that is used to control Avaya Communication Manager PBX directly (not via phones). Centralized event notification and call control is provided via Application Enablement Services gateway (formerly Avaya CT) with variety of protocols and APIs, including JTAPI.
Hope it was helpful.
Regards,
Alex.
You could try to use one of the following tools, among others, to make the task more trivial.
SWIG: http://www.swig.org/
JNA: http://jna.java.net/
JavaCPP: http://code.google.com/p/javacpp/
Being the author of the third there, I recommend that one :)

Java vs Flash for webcam access

I will make a video chat website, but coming from PHP and Python for the web i have no experience with video steaming.
What do you recommend? Java or Flash? What's more flexible ?
I am thinking of even making a C++ server application for stream controlling with a PHP fronted. Since is going to be a high traffic website and performance is a must.
Can you point to some direction?
Any documentation? Framework?
I'm going to warn you: this is no small project. There's a reason why most prepackaged video chat websites and services cost hundreds of dollars a month.
First off, you need to pick your client side runtime. This is a major decision, since it will impact your available client base, and the cost of entry for your site. Flash is hands down the most pervasive, but Java is fairly prevalent in the techie culture. Silverlight less so, but you should check the latest statistics. Note that you should pick a particular version you're going to develop for, since the APIs may change, and market penetration is different.
Once you've developed the client-side code, you'll need to pick the server environment. If you use Silverlight, obviously you need to use C#.NET to develop the server side code (for the video streaming). Both Java and Flash as clients use Java as the server-end.
If you choose to go with Flash, be aware that you can either go with the official Flash Media Server, or you can go with the open-source Red5 server.
As noted by SEK, you should proceed with caution since providing a reliable streaming service might not be as easy as it sounds.
I would recommend reading about streaming (what it is/means, technologies, etc) and then moving on with the implementation.
Serving streams to clients
Solutions like the Flash Media Server, might give you less headaches. Red5, as previously mentioned is a 'nice' open source solution, although i am not sure about the capacity and stability.
You might want to check:
http://www.wowzamedia.com/ (Flash Media Server) - interesting
NOTE: Wowza Media Server 2 for Amazon EC2 is also available
http://mammothserver.org/ (Another Open source Flash Media Server)
http://fmsguru.com/ (Flash Media related tutorials)
Google is always your friend on this big topic..good luck.

Operator Console App - Java/Flex

We are in the middle to evaluate the technology choice to re-design an operator console application. The operator console as a hosted contact center has the abilities to queue the inactive calls, and hold, answer, transfer the active calls.
The legacy operator console used Java Swing. We want to use the latest RIA technology (Flex/Silverlight) to retire the legacy one. But the question is Flex/Silverlight can implement the functions like hold, transfer the calls? Based on my experiences, Flex can listen Java socket to receive XML data? Does it work well to receive voice data? Thanks.
Flash / Flex does have native access to the computer's microphone with the introduction of the latest player / AIR runtimes. But, that is probably not what you need.
Yes, Flex supports open sockets and can listn to a server. To receive voice data, you'll be best served using something on the server side, such as Flash Media Server or Red5.
I'm not sure of the technology to integrate such technologies with a traditional phone lines, though. You may look into Ribbit APIs as one solution. I was under the impression that Ribbit used Red5 under the hood; and it designed for these type of telephony applications.
You can use flex and Ribbit for that. Ribbit is a company that offers VOIP solutions for web application. I have used in couple of projects and it's really good.
Here is the link to their deve zone (htey support several technologies):
http://developer.ribbit.com/development-center/flash/flash-center
Hope this helps.

Categories

Resources