Right now a lot of my applications use GWT-RPC for retrieving POJO's from a GWT RemoteService which in turn calls a Web Service (SOAP) to get the data. I am evaluating Flex and didn't really see anything truly analogous to this simple architecture. Anything I may have missed?
AMF is Adobe's compact binary message format for use in Flash / Flex applications. BlazeDS is the open source reference implementation for Java, using essentially nothing more than a simple "message broker" servlet to handle requests. This is similar to how services are exposed in GWT, although Blaze uses a single servlet, not multiple as in GWT.
http://opensource.adobe.com/wiki/display/blazeds/BlazeDS/
http://download.macromedia.com/pub/labs/amf/amf3_spec_121207.pdf
BlazeDS, particularly with Spring Integration.
Does this help you? I'm not too familiar with GWT-RPC, but is the AMF protocol what you're looking for?
As others have mentioned, the main choice here is BlazeDS, which is Adobe's open-sores server product for exposing flex-native server RPC and messaging. BlazeDS on its own is a bit clunky, and if you use Spring on the server, there is a slick integration available between Spring and Blaze.
Another, 3rd-party alternative is GraniteDS, which does much the same thing as Blaze, but is Spring-friendly out of the box, and does quite a lot more than Blaze (e.g. runtime compilation and generation of SWF files from the webapp). I haven't tried Granite, but it looks pretty good.
Related
I'm selecting a framework for restful service. Restlet looks promising. However, I'd like to pick something that's mainstream enough that it won't go out of support/development too soon. I know restlet has been around for quite some years. However, I'd like to know if it's popular enough. My questions are,
Any big name companies using it?
Is the default http server good enough for production?
thanks
The Restlet Framework has been available since 2005 when it was the first RESTful web framework for Java. It has support for the JAX-RS API, but its own Restlet API is both client and server-side since day one, much more comprehensive and extensible. We are free to innovate based on our community feed-back, without having to go through lengthy JCP standardization processes.
Also, we just published the 'Restlet in Action' book last September along with its version 2.1. Our internal connector is fully asynchronous and based on NIO and we are constantly stabilizing it even though it isn't ready for heavy productions yet (use the Jetty connector or a Java EE container with no change to your Restlet application).
Its consistent support for Java SE/EE, OSGi, Android, GAE and GWT with dedicated editions is unique. A port to JS (Node.js + AJAX) is also under way. We have also started work on version 2.2 with the first milestone being released (with full Java 6 support, OAuth 2.0 extension based on the final spec, etc.).
In term of references, we have many large companies using it including LinkedIn (see their GLU open source project), IBM, NVidia, ForgeRock, NASA, Sonatype, Apache Camel, Mule ESB, etc. Google has been using it internally as well. See some quotes here:
http://restlet.com/discover/quotes
In January, we'll launch a new community web site as well as APISpark, an all-in-one platform to create, host, manage and use web APIs, directly based on Restlet Framework (PaaS), so the project is active and has an exciting future!
Best regards,
Jerome Louvel
PS: I'm the Restlet Framework creator and lead developer.
The most mainstream you can get is Jersey. It is the official implementation of rest in java. Restlet came out before Jersey. But then Jersey surpassed them (in my humble opinion). I have used both Jersey and Restlet on serious projects. They are both good. However, you will find more support, more books, and more examples on Jersey.
Is this about Java? In that case, JAX-RS is the awesome new API for doing this. The best book for this is Restful Java with JAX-RS. My favorite implementation of it is Jersey, but there are others with their own unique features. All JAX-RS implementations are compatible if you don't use their distinctive features (which are minor anyway). The book explains the core API, the REST philosophy, and also some of the features unique to the different implementations. It is an excellent book. I love the introduction, where the author relates how he was used to traditional remote procedure call (like SOAP, WCF, and ordinary OO semantics) but then saw the light of the REST principles as being simpler and more elegant.
I use Tomcat as the HTTP server (servlet container). It is lightweight and is what Amazon Beanstalk uses (you can just upload your application, the WAR file, to it and it just works). You can also use GlassFish which supports many more JavaEE features, or use Apache for static pages and other things, and forward the REST requests to Tomcat/GlassFish.
The annoying thing about JAX-RS is that it's so powerful and easy that you're tempted to write ideologically-sound REST services. Unfortunately, javascript can't use many of the REST features (setting Accept header, calling anything but GET/POST, etc.) But it's not a big deal.
Jersey also has a fantastic client-side Java API that mirrors JAX-RS and reuses the same annotated classes, if your clients will be Java.
From the article
The Servlet API was released in 1998 and its core design hasn't
significantly changed since that time. It is one of the most
successful Java EE APIs, but it suffers from several design flaws and
limitations. For example, the mapping between the URI patterns and the
handlers is limited and centralized in one configuration file. Also,
it gives control of the socket streams directly to the application
developer, preventing some IO optimizations by the Servlet containers
like the full usage of NIO features. Finally it does not support HTTP
features like caching, content negotiation and content compression
very well, causing too much pain to developers and preventing them to
focus on their application specific code.
Another major concern was the lack of a modern HTTP client API in the
Java EE stack. The JDK's HttpURLConnection class is hard to use and
leaves too much HTTP features unsupported like expressing client
preferences for content negotiation.
Frequently, people were relying on third-party HTTP client APIs to
workaround those limitations. Again, NIO can't be supported with
HttpURLConnection.
In 2005, I saw an opportunity to go beyond all those limitations, and
to design a fresh API in the light of the REST principles. For the
first time, we have an API that unifies client-side and server-side
Web applications, an API that fully supports NIO and an API that lets
the developer programmatically control its container, connectors and
deployed applications without having to constantly rely on XML
descriptors.
I am looking for approaches I can take to consume my .net SOAP service on the BlackBerry Playbook. So far I believe there are two main approaches to my problem.
Apache CXF wsdl2js
I have used wsdl2js to generate the javascript needed to communicate with the service. However I end up getting a http 500 error and have not been able to get past that. I have looked through the provided examples from the Apache CXF download and I have done some searching and cannot find a solid example of creating the javascript client. A lot of examples seem to somehow access the wsdl file at runtime from a server but my javascript is already generated from the CXF tool and I just include the scripts... if anyone has some tips here that would be great.
Adobe Flex and AS3
Another option I have considered is using Adobe Flex. I create a new Mobile Flex project in Flash Builder using the BlackBerry PlayBook SDK and Flex 4.5. However when I use the menu options to connect to a web service I get prompted with "This option is only available for flex projects."
Are there any other options out there that provide a solution to this problem? If you need more information just let me know.I understand this is a large topic, thank you for your time.
In Flex, you can use the WebService class to access SOAP WebServices. More info here.. I'm sure you can use this class for a non-Flex AS3 solution.
I'm not sure why they disable the Flash Builder tooling for this; but it shouldn't prevent you from using the actual classes to access WebServices.
I can't speak about the alternate approaches.
Let me start off by stating that I am a novice developer, so please excuse the elementary nature of my question(s).
I am currently working on a Flex Application, and am getting more and more confused about when to use server side scripting, and when to develop web services. For most of the functionality I am working on, I am taking various files from the user (client), uploading to the server for processing/conversion, then sending back to client in new format.
I am accomplishing most of this using asp.net generic handlers (ashx) files, but not very confident this is best practice. But at the same time, does making web services make any more sense? What would be considered best practice for this? Any suggestions would be greatly appreciated.
The way I look at it is as follows:
Web Services mean Established Best Practice.
For most of our development, we don't need to create "Web Services", or what I'm thinking when I think REST, SOAP, and the Twitter API. You only need to start doing that once you've got something you're going to be using every day for years.
Clean and DRY code will Lead you to Creating a Web Service
If you spend the time to clearly define the parts of your upload-process-render Architecture, and you find that it can be applied to almost everything you are doing, then all you need to do to make it a Web Service is define a clear, 1-2-3 set of rules for using the system (GET/POST data, etc.). As long as you are consciously building an architecture the whole way, you'll end up creating a Web Service if it's worthy. Otherwise there's no need.
It sounds like you have a clear workflow going, I don't know anything about asp.net though.
As far as it being confusing sometimes, and best practices, I suggest the following:
Create a Flex Library Project for your "generic ashx file handling" Flex classes. Give it a cool, simple name.
Create a .NET Library Project that encapsulates all the logic for your server-side file processing. Host it online and make it open source. I recommend github. Test it as you go, and document it, its purpose and the theory behind it.
If you don't have to do anymore work at this point, and it's just plug and chug, then you've probably arrived at something that might become a Web Service, though that's probably a few years down the road.
I don't think you should try to create a Web Service right off the bat. Just make some clean and reusable code, make a few examples, get it online and open source, have others contribute and give feedback, and if it solves a specific problem, then make it a web service. You can just use REST for now probably, and build your system around that. RestfulX is a great library for that.
Best,
Lance
making web services without any sense make no sense ;)
Now in the world of FLEX as3 with flash version 10, you can easily read local files, modify them with whatever modifcation algorithm and save local files without pinging server.
You only have to use webservices if you want to get some server data or to send some data to server. that's all.
RSTanvir
Flash / Flex uses a simple HTTP POST approach for file uploads, so trying to do that using SOAP web services will be problematic. Your approach of using ASHX here sounds reasonable to me.
To send / receive data that isn't file based (e.g. a list of files the user has uploaded previously), I would recommend looking at the open source Fluorine FX library. Fluorine uses AMF which is a highly performant way of doing data transfer with Flash. It's also purely configuration-based, which means you don't need to code against any of its APIs, just configure Fluorine to expose your .NET service classes. You could easily add attributes to those same classes to expose them as SOAP web services via WCF if you need that in the future. I would not recommend using SOAP with Flex however, due to the performance losses and also because the Flex implementation of SOAP has a history of bugs and interoperability problems.
What are some of the advantages in adding Spring into a Flex / AIR application? And When would you recommend using Spring?
If you're writing a Flex app with a Java backend, you'll want to use BlazeDS to handle remoting and/or messaging between the client and server. Spring has support for integrating with BlazeDS and making Blaze a little easier to setup and configure. It's also pretty easy to set up BlazeDS on its own, so if you don't want to learn Spring then you should not be afraid to use BlazeDS by itself.
The bulk of what Spring provides is specific to the Java layer but it will help you write better Java applications. In particular it provides a clean way for wiring up application components, simplifies data access using Hibernate and/or JDBC, makes it easy to do aspect-oriented programming and also has a pretty nice security framework (Spring Security). There's a ton that Spring can do and I recommend using Spring for pretty much any Java backend.
Flex is addressing what happens in the UI. You are likely to need some server-side logic to provide the data for the UI. Writing robust, performant, secure server-side logic from scratch is not trivial. Frameworks such as Spring, EJB 3, etc. really do help with that. The learning curve for modern frameworks is not too steep, getting started is barely more that a few extra "annotations" to the code you knew you wanted to write.
Well worth investigating.
The sum total of learning Flex + Spring + also some DB admin is still quite a lot. You may need to keep your ambitions under control, don't try to fly before you are walking comfortably.
Good luck.
How do I get AS3 and/or Flex/AIR applications to communicate with CORBA apps?
Until somebody writes a CORBA-compliant library for Flex (which you may care to do yourself ;), your best bet may be to build a 'wrapper' web service (accessible via the standard Flex WebService object) that acts as a bridge.
I think you need to make some sort of proxy, like a Java server that you connect to. I don't think there are any CORBA libraries for AS3. I could be wrong though...
From what I know it is possible to call Java from Flex (at least you get lot's of google results for that :-) )
Given that I would recommend to do an experiment if you can use a Java ORB (I would recommend JacORB (http://www.jacorb.org/) and see if you can use it from flex.