Is there any java library available to use Windows Azure AppFabric Caching features?
I want to put some string in the AppFabric cache from a java application and retrieve it from a .Net application (and the other way around too).
AppFabric SDK for Java Developers provides classes to access AppFabric Access Control and Service Bus, but it doesn't provide classes to access Caching features.
Thanks in advance
I think you've got two options here:-
Reproduce in java, from a client perspective the mechanism that the appfabric client uses to interact with the cache cluster. You'll need to sniff out the tcp messages that the appfabric client wcf creates and reproduce them.
Expose a mechanism from your ASP.NET app that wraps the call to the .net AppFabric client and make your Java app call the wrapper. The wrapper could expose a SOAP or restful interface - you could provide CRUD cache methods.
If I were you I'd, do the latter. I think it'd be faster to implement and easier to test.
Seems to be impossible to have a native client because of tcp transport and serialization (deserializing in java ...). A WCF service using a basicHttpBinding can solve your problem. The problem is that is will need a separate hosting and it will not as fast as AppFabric native client.
Related
2 month ago i started to develop an android application which needs to call remote methods and receive complex objects (custom objects with custom feilds in it) from a server.
My friend and I splitted the work so he worked on the android client and i on the server.
Before we started, we built the base interfaces which provide the functions that the client needs from the server, so my friend can program easly the application (by using fake classes as implementation for the interfaces), and after i finish the implemntations of the interfaces in the server-side he will make the connection and call the functions from the server and not from the fake classes.
Now the problem is that we can't find a way to pass those interfaces from the server to the client.
We tried to use java RMI, but we faild because android doesn't support java RMI,
then we tried to use JAX-WS (with tomcat 7) and we also faild because JAXB can't handle intefaces. (-you can see more details here about jaxb issue-)
My friend and I feel really lost.. we don't have any idea how to pass those interfaces between the server and the android client.
Is it possible what we're trying to do? if not,
what other options avaible for us to call remote methods and receive complex objects from the server?
Thanks!
You can expose webservices on the Server, so the client can interact with the server whenever its needed that might be quickest solution.
Or you can write a kind of servlet programming to get the json request from the client, process it and send the json respoonse back to the client. If the application is data intensive, the JSON helps you a lot
Not sure if this is too late now (after 2 months of development), but there are frameworks that should make RPC easier for you (take care of linking both ends). Two I know of are Apache Thrift (definitely usable with Android - there are apps that use it) or Apache Etch (possibly).
Apache Thrift:
http://thrift.apache.org/
Apache Etch:
http://incubator.apache.org/etch/
Blog about Evernote choice of Thrift:
http://blog.evernote.com/tech/2011/05/26/evernote-and-thrift/
If your application is limited to communication between Java on the server and Android (no other clients e.g. IOS) then an easier RPC path compared with IDL based solutions is to use jsonrpc. This solution provides both server and Android client components. It is extremely easy to implement on both client and server. One limitation is that byte arrays have to be encoded because the JSON transport does not support binary.
I have developed my DAL using Entity Framework (Self Tracking Entities). I have written a WCF Service which exposes some CRUDE operations on those STEs.
I want to use my WCF service in a java application (client).
Would the STEs work properly in my Java Client Application? I mean if the java client application makes some changes in my self tracking entity, will those changes be tracked?
No. STEs work only if you share assembly with their logic between server and client application. Once your client application is Java it cannot use your assembly with STE logic (with advanced interop it probably can but that is not solution for bad design of your service) so either Java developers must code the whole logic again or you must use plain POCOs / DTOs without this auto magic. WCF service exposing data sets or STEs is not interoperable because it demands certain logic implemented on clients.
Btw. we warned you about disadvantages of STEs!
I don't think this is quite possible or if it is recommended to do... but is there a way to connect or comunicate or deploy Java and .NET application for method beside Web Services. I mean I understand there are Messaging server that allows Java application communicate to each other but I dont know if this can cross development environment, any suggestion about it or thoughts about this?
I'm limited to web and desktop environments.
Apache Thrift is a way to go. You will need to write a service definition like this:
serivce helloworld{
string sayHello(1:string name)
}
Thrift then will generate RPC interface with network layer already implemented, It support many others language such as Java, C#, PHP, Python. Thrift support binary protocol over TCP/IP, so it's very fast.
for more, go to its wiki page http://wiki.apache.org/thrift/
You can use something like Apache ActiveMQ which uses JMS on the Java side and the .NET Messaging API on the .NET side.
We ended up writing our own implementation of Java-.Net communication protocol based on Hessian (later added JSON as well), but Thrift is a valid option.
The virtual machines (JVM vs CLR) are not going to talk to each other except through some OS level open standard. Shared Files (yuck), Sockets and Web Services come to mind. There is nothing that would allow you to call a .net subroutine from java or vice-versa.
I'm in the process of writing a client/server application which should work message based. I would like re-use as much as possible instead of writing another implementation and curious what others are using.
Features the library should offer:
client and server side functionality
should work message based
support multi-threading
should work behind load balancer / firewalls
I did several tests with HTTPCore, but the bottom line is that one has to implement both client and server, only the transport layer would be covered. RMI is not an option either due to the network related requirements.
Any ideas are highly appreciated.
Details
My idea is to implement a client/server wrapper which handles the client communication (including user/password validation) and writes incoming requests to a JMS queue:
#1 User --> Wrapper (Check for user/password) --> JMS --> "Server"
#2 User polls Wrapper which polls JMS
Separate processes will handle the requests and can reply via wrapper to the clients. I'd like to use JMS because:
it handles persistence quite well
load balancing - it's easy to handle peaks by adding additional servers as consumer
JMSTimeToLive comes in handy too
Unfortunately I don't see a way to use JMS on it's own, because clients should only have access to their messages and the setup of different users on JMS side doesn't sound feasible either.
Well, HTTP is probably the best supported in terms of client and server code implementing it - but it may well be completely inappropriate based on your requirements. We'll need to actually see some requirements (or at least a vague idea of what the application is like) before we can really advise you properly.
RMI works nicely for us. There are limitations, such as not being able to call back to the client unless you can connect directly to that computer (does not work if client is behind a firewall). You can also easily wrap your communication in SSL or tunnel it over HTTP which can be wrapped in SSL.
If you do end up using this remember to always set the serial version of a class that is distributed to the client. You can set it to 1L when you create it, or if the client already has the class use serialver.exe to discover the existing class's serial. Otherwise as soon as you change or add a public method or variable compatibility with existing clients will break.
static final long serialVersionUID = 1L
EDIT: Each RMI request that comes into the server gets its own thread. You don't have to handle this yourself.
EDIT: I think some details were added later in the question. You can tunnel RMI over HTTP, then you could use a load balancer with it.
I've recently started playing with Hessian and it shows a lot of promise. It natively uses HTTP which makes it simpler than RMI over HTTP and it's a binary protocol which means it's faster than all the XML-based protocols. It's very easy to get Hessian going. I recently did this by embedding Jetty in our app, configuring the Hessian Servlet and making it implement our API interface. The great thing about Hessian is it's simplicity... nothing like JMS or RMI over HTTP. There are also libraries for Hessian in other languages.
I'd say the best-supported, if not best-implemented, client/server communications package for Java is Sun's RMI (Remote Method Invocation). It's included with the standard Java class library, and gets the job done, even if it's not the fastest option out there. And, of course, it's supported by Sun. I implemented a turn-based gaming framework with it several years ago, and it was quite stable.
It is difficult to make a suggestion based on the information given but possibly the use of TemporaryQueues e.g. dynamically created PTP destinations on a per client basis might fit the problem?
Here is a reasonable overview.
Did you tried RMI or CORBA? With both of them you can distribute your logic and create Sessions
Use Spring....Then pick and choose the protocol.
We're standardizing on Adobe's AMF as we're using Adobe Flex/AIR in the client-tier and Java6/Tomcat6/BlazeDS/Spring-Framework2.5/iBATIS2.3.4/ActiveMQ-JMS5.2 in our middle-tier stack (Oracle 10g back-end).
Because we're standardizing on Flex client-side development, AMF and BlazeDS (now better coupled to Spring thanks to Adobe and SpringSource cooperating on the integration), are the most efficient and convenient means we can employ to interact with the server-side.
We also heavily build on JMS messaging in the data center - BlazeDS enables us to bridge our Flex clients as JMS topic subscribers. That is extremely powerful and effective.
Our Flex .swf and Java .class code is bundled into the same .jar file for deployment. That way the correct version of the client code will be deployed to interact with the corresponding middle-tier java code that will process client service calls (or messaging operations). That has always been a bane of client-server computing - making sure the correct versions of the respective tiers are hooked up to each other. We've effectively solved that age-old problem with our particular approach to packaging and deployment.
All of our client-server interactions work over HTTP/HTTPS ports 80 and 443. Even the server-side messaging push we do with BlazeDS bridged to our ActiveMQ JMS message broker.
Besides using Web Services, or POX (or custom HTTP), are there some other techniques that I could utilize for calling services exposed from WCF via ___________ to the Java world? These requests will be in the same machine. Maybe RAW TCP/IP?
I'm just inquiring for a project that we need to possible provide some method of calling synchronous code in the .NET world and return results to our Java world.
Thanks for suggestions.
To talk with a Java client you'll have to use one of the interoperable protocols which limits you to going across HTTP or HTTPS. TCP can only be used between clients running Windows on an intranet. Even on the same machine you won't be able to use Named Pipes either for the same reason.
The interoperable protocols are covered in Chapter 1 of "Programming WCF Services" by Juval Lowy.
You can try following project http://iiop-net.sourceforge.net/