I read Bill Burkes book "Restful Java with JAX-RS" (2009) and when he wrote about frameworks (RESTEasy, Apache CXF, Jersey), specially about frameworks which support the client side implementation, he said:
There is a lot
of interest from the JAX-RS specification lead and expert group members to get a
standardized client framework baked into JAX-RS 2.0.
Am I right when I say, there isnt a standardized client framework yet? Will there ever be one?
I thought about writing a 60 pages long work about the different frameworks with regard to client side implementation. At the end maybe a prototype of an own implementation, with some good ideas. Do you think it's a good issue to discuss about? Do you have ideas what else I could consider in this discussion?
I think, you need to be very clear on what the objective of such a paper would be. Ie. what the interesting application of your findings would be.
Do you e.g. intend to submit it as input to the JAX-RS specification board, or publish it as a white-paper for solution architects or even as a scientific paper? If not, then I agree with Donal Fellows on that 60 pages is way too much, and that you otherwise probably will need more than that to establish your methodology, describe the experiments including how they relate to the objective, analyse your findings, and so on. And if you also want to try your own hand in creating a client framework, then you will quickly come close to the extend of a postgraduate thesis...
On the other hand, am I certain, that we are many practitioners, who are reluctant to embrace JAX-RS as long, as there are no mature ways of consuming the services it enable us to produce. It should however be possible evaluate the different options in a more accessible form than a 60-page report.
If you decide to go ahead with making some sort of paper about this, I (too?) will be interested in seeing the result.
Also, I am curious of, whether any of the JAX-RS frameworks supports "dynamic" clients based on runtime binding of URI templates delivered from the server.
Related
I am fairly new to building applications using the RESTful architecture. As a matter of fact, all I have done so far is categorized as Level 2 REST by Leonard Richardson and that I know Fielding would happily categorize as Non-RESTful.
I have spent hours trying to understand HATEOAS and how to reach level 4. And I see it more clearly now. I conceptualize the application as a series of state transitions, and the resources will dynamically provide links with information on how to move from one state to another.
But everything related to HATEOAS seem to be inherent of a human-computer interaction. I mean, even when the resources provide the links that enable the application user to move to the next state, it is ultimately the user the one that drives the application from one state to the other by causing the use of of the provided links.
But how are things supposed to work when we are dealing with computer-to-computer interaction? After all when it comes to service-orientation the idea of service composition is key, and we cannot naively assume that the client is always going to be a human being? Many services are designed to be consumed by non-human users, and some interactions/orchestrations might be fairly complex, the type of things that are typically modeled with things like BPM, or BPEL.
Is REST and particularly HATEOAS only usable in applications that imply human intervention and if not how is this supposed to work otherwise?
I am getting this vibe that REST is only good for certain type of solutions and inadequate for others, but literature out there has failed to explain those inadequacies and sell REST as the cure of all evil, but I just don't quite get how to use for proper service composition when humans are not the drivers.
I'd really appreciate any references or insights on this, because believe me I have two days straight reading all I have been able to find on this topic and I have not yet being able to reach any reasonable and well documented conclusions.
Well, your client app can parse the response to get possible actions. In this case actual urls are obtained not from knowledge of the API, but upon calling the initial method (usually GET). All human-less.
It sounds almost as if you're comparing SOA to REST/Hypermedia and fail to see that SOA is a strategy, for designing a complex system made out of other systems, while REST/Hypermedia is a software architecture style applying a bunch of constraints on client-server communication. The client, however, can be both a server or a human, it doesn't matter.
To use or not to use REST/Hypermedia is not something to bother with when outlining/designing service composition. It's a question that comes into play when trying to achieve syntactic interoperability. Many times it comes down to comparing REST to Soap and other technical details.
I'm just getting into the client-server data sync stage of my iPhone app project, and have managed to get my CoreData data model loading on both the iPhone client and my TurboGears server (which is good). I'm now beginning to tackle the problem of sync'ing data between the server and multiple clients, and while I could roll my own, this seems like one of those problems that is quite general and therefore there should be frameworks or libraries out there that provide a good deal of the functionality.
Does anyone know of one that might be applicable to this environment (e.g. Objective-C on iPhone, pyobjc / Python on the server)? If not, does anyone know of a design pattern or generally-agreed upon approach for this stuff that would be a good road to take for a self-implementation? I couldn't find a generally accepted term for this problem beyond "data synchronization" or "remote object persistence", neither of which hit much useful on Google.
I did come across the Funambol framework which looks like it provides this exact type of functionality, however, it is C++ / Java based and therefore seems like it might not be a good fit for the specific languages in my project.
Any help much appreciated.
Since you are using TurboGears already, take a look at the RestController documentation. Using RESTful services has become a widely adopted architecture with many implementations for both clients and servers. Matt Gemmell's MGTwitterEngine is a good example of the client implementation of a specific API, Twitter.
I was today trying to figure out on working with WebService and found many articles really gospel over the Web Service and its effectiveness in the Market share.
My Questions are:
For a Complex project of critical data, is it better to opt for WebService?
What Makes WebService different from other way of fetching the data?
The answer is... it depends. Web services are not really the next Big thing, they have been a Huge Thing for years now. In business applications, web services allow a big level of interoperability and capabilities never seen before.
They help integration with legacy systems, cooperation between distinct departments, defining loosely coupled interfaces and such. You should read some about Service-oriented architecture.
If all you need is a PHP application that handles data from a single database, you might not need web services at all. If you are designing a solution that revolves around multiple data sources, with complex security involved, multiple languages and/or multiple applications, then web services become essential.
SOAP is a protocol; if working with PHP, you'll need to check out the PHP: SOAP guide to understand how it works. For every language (almost), there are existing APIs to develop web services. Anyhow you might want to check RESTful web services instead of SOAP-based ones, they are generally simpler to implement/understand. But that's another debate ;-).
Cheers.
That mostly depends on the definition of "big thing".
My experience with the WS stack and SOAP and all the acronym soup is that it takes an awful lot of workforce to deploy it. The status of the frameworks is complex, and definitely not something a hobbyist can put to work in a couple of afternoons. We have seen how many things on the net became the next big thing just because they were easy. Easy to understand, easy to interact with, easy in technology. Wikipedia, twitter, digg, youtube are internet big things, and they are, from the interaction point of view, light years away from SOAP/WS based interaction. They are KISS: simple and stupid. A whole horizontal market was opened just because of their simplicity. Even multiprocessing platforms like BOINC don't use anything near the WS stack, but they are the core of many high-throughput efforts.
Now, if you have to deal with complex multi-host transactions, authentication, credential delegation, caching... WS is there. It's the target that makes the need: banks, flight reservation, stuff like this. but they won't impact the common programmer. They require too much energy and too many different competences at once to become something usable for a horizontal market of developers.
Also, I am a REST person. I never advocated SOAP with much emphasis, but there was nothing else and it was a better evolution over XMLRPC (which, if you have to perform dumb RPC, IMHO it's still a good choice). Now I changed my mind. You mostly have resources on the web, and you interact with them with HTTP methods. SOAP is nothing but RPC on hypersteroids. No, REST is not the solution that replaces WS. At all. it's simply easier to use and to debug, albeit more difficult to design (you have to think in terms of resources instead of method calls). It's KISS. That's why it has more chances for success on the horizontal market.
It depends.
Web services can be useful if you need to expose the data across security boundaries, where a direct connection to an RDBMS would be a bad idea.
Popular method for implementing web services nowdays is to use RESTful API (eg. via Ajax/JSON). It's already "next big thing" – almost every major player has been offering it for years. Google, Flickr, Twitter, you name it.
The big advantage is that they help to implement an API layer.
If you implement your solution using a "bus" where the web services sit, it opens up your product to a far greater range of users and moves away from being a proprietary product.
It also enables people to interface using a wide range of solutions e.g web service clients can be implemented using command line, Jsp, Java, Asp, .NET, PHP etc.
They also enable code re-use e.g. if you implement GetClientDetails (ID) as a web service for one user, when the next group comes along wanting the same thing, all you have to do is give them the WSDL and they are away.
Update: This question was inspired by my larger quest for mapping ontologically the whole software systems architecture enchilada. I've written a blog post about it, and hopefully it will help clarify what I'm after.
Many, many, many frameworks and stacks that's event-driven have too much variation for my little head to get around. Is there somewhere some resources that defines the outline of a reasonable Application Event Model, what events there are, and what triggers are most common?
I've got my own framework with a plugin and event-driven architecture, but I want to open-source it, and as such would like to make it closer to some common ground as not to alienate people.
So to clarify; this is for an application, meaning setting up the environment, the dependencies, the data sources (like databases), and being a MVC framework setting up the model, the view, launching controllers / actions, and in the GUI various stages of the interface (header, content, columns, etc.).
Ideas? Thoughts? Pointers? (And I've made it language and platform neutral at this point)
I read your blog entry, which btw I found an extremely interesting read, but... this question does not seem to reflect the broadness of the issue you are presenting there.
What you are after is very abstract and theoretical. What I mean to say is that if you tie any of those ideas to actual technology you will find yourself 'stuck' with it. This is why many of us are reluctant to use any framework. Especially the 'relabeled' products suddenly claiming to conform to the trend. We choose mainly on the basis of what appears to be needed to reach a predetermined result.
Frameworks (or tools in general) that target the application architecture domain distinguish themselves primarily by the amount of responsibility they are designed to take on. Spring for example only deals with the concept of decoupling and is therefore easily adopted and useable in many situations. The quality of any framework is expressed in terms of how well the designers of such frameworks were able to keep their products within the boundaries of that responsibility. Some front-to-end products will do exactly the opposite, code generators being among the 'worst' of them.
To answer your question at the top of this page, I do not think there is a framework that does what you want at this time and I do not think there is a single model of how applications (should) work. Keep in mind though that the application architecture domain deals with technology more than it does with concepts. In other words: If it works and meets the requirements, then you're pretty much done.
That said, you might find something of value in agent-based systems.
Heh. Most developers pick the major framework they like the tools for and stick with it. That's usually the winning strategy. I sympathize with your desire not to marry a single vendor.
Keep in mind however, that in developing your own framework, you're going to end up tied to a single vendor anyway. :-)
Is there somewhere some resources that defines the outline of a reasonable
Application Event Model, what events there are, and what triggers are most common?
I don't think so.
From what I see, there are two kinds of models out there: those with a real framework with which you can make a working data entry dialog, and abstract meta-meta-models that are optimized for modeling themselves.
Try surveying a few current frameworks that have good documentation online and cross-reference the major terminology in a spreadsheet. It's an interesting exercise.
I'd have a look at Spring for Java, and the XT Framework Spring module (http://springmodules.dev.java.net/docs/reference/0.9/html/xt.html), which apparently supports event-driven architecture, as starting points. Spring has an MVC framework (inc. convention-based routing to controllers), db configuration (for Hibernate, particularly), plus full dependency injection support. There's also a mechanism in Spring for modularising your web apps, called Spring Slices. And it can be integrated with Jersey for building RESTful apps.
(Unfortunately, I tried to provide links to everything, but this place only lets new users post a single link. So you'll have to do some googling :) )
Are people still writing SOAP services or is it a technology that has passed its architectural shelf life? Are people returning to binary formats?
The alternative to SOAP is not binary formats.
I think you're seeing a surge in the desire to leave the complexities of WS-* behind in favor of REST and JSON, because they're much simpler to use and don't require frameworks to be used successfully. The problems that WS-* ostensibly tries to solve aren't problems for most users, but they have to pay for the complexity any way.
I still write WS-*–based services. Somewhat surprisingly, I've had less trouble with them when trying to inter-operate with less capable developers. This is because if I send them a WSDL file, they know how to crank it through their tool and get an API they can call, while being blissfully unaware what is happening under the hood. To give customers a REST-ful service, I have to start talking to them about HTTP and XML, which they really don't understand as well as they think they do, and then I start getting a headache.
In other words, to be successful with REST, both the service provider and consumer have to know what they're doing (and they can keep things simple and come up with a great, non–WS-* solution). With WS-* technologies, it can still succeed even if only one party has a clue.
I think, however, that REST-oriented standards that are much less complicated than current WS standards, will eventually emerge, and when that happens, comparable tools will be available too.
I think so. RESTful solutions are more and more sensible for the vast majority of use cases; the complexities of SOAP and other RPC technologies just aren't worth the effort anymore.
I wouldn't consider SOAP legacy at all. REST vs. SOAP is really just the continuation of the debate of COM/CORBA vs. HTTP POST/GET etc. SOAP is nothing more than an updated version of the same principles defined with C and C (contracts, providers, consumers etc.). It's just that has appeared to SOAP succeed (at least partially) where the other two failed (and it could be that SOAP just has a better marketing team), that is that SOAP really does allow to different systems to connect rather easily compared to it's predecessors. That being said, it still suffers from the same drawbacks that COM/CORBA did...it can get really complex.
I think REST is just coming back into style at the moment. It's nothing new, people are just taking another look at it. Look at the web. It's REST and it's been around for years. 5 years from now people are going to look back and say the same thing about it being legacy and the need to change. It's the nature of software development. Everything goes in cycles.
The debate about which one is better is going to be just like the tabs vs. spaces debate. There are going to be people on different sides swearing that one is better. Really in the end, they both accomplish the same goal. Sure one will be a better solution than the other in some situations, but in the end neither will be superior 100% of the time.
We were using SOAP, but since we control both messaging endpoints (thick client out on the web connecting to our servers) we decided that the "lingua franca" of XML wasn't offering any real benefit. Instead, we're experimenting with binary serialization via Google protocol buffers, and like everything we've learned so far. It's somewhat CORBA-esque, but doesn't make me grumpy the way CORBA did. Still haven't found the best fit for the RPC layer, but pretty sure the payload will be protocol buffers.
The point I'm trying to make is that if you control both sides of the conversation, there are significant efficiency advantages in bypassing the XML tax.
Yes, some people still are (and now it's 2011!). I think the main reason is that MS WCF automatically generates SOAP bindings. The horror.
It's impossible to define what the best technology solution is without considering what the problem is, in other words, what the context is. Both REST and SOAP have their place. If you have a high traffic site and a development audience who is comfortable with REST, then SOAP would be a bad choice, primarily because the message size is so incredibly bloated. If you have small scale site with a modest development budget, then SOAP will be a superior choice due to automatic proxy generation from WSDL. To make a fair comparison, it should be mentioned that implementing a REST conversation takes more development time and therefore is more expensive, a very relevant fact for your boss.
While it is true that SOAP is a more complicated protocol, in my experience this doesn't translate to maintainability issues. That's because messages ride on HTTP and can be easily debugged just like REST message, and the SOAP stacks available on major platforms are very solid.
The complexity of SOAP is of course an advantage if your requirements include sophisticated items like federated message security. On the other hand, these kind of requirements are not seen that often in my experience. The WS standards committee may have been vulnerable to some YAGNI issues. Now that web service communication is commonplace, it's turning out to be simpler that was originally envisioned.