|
Sponsored Links
Resources
Enterprise Java
Research Library
Get Java white papers, product information, case studies and webcasts
|
News
News
News
|
Messages: 37
Messages: 37
Messages: 37
Printer friendly
Printer friendly
Printer friendly
Post reply
Post reply
Post reply
XML
XML
XML
|
 |
REST vs. WS-*, a Parable
Elliotte Rusty Harold has written "REST vs. WS-*: a Parable," discussing the differences in approach between REST and - for lack of a better term - traditional Web services, represented by the multitude of W3C specifications. In it, he uses a protagonist who represents REST, as the simple, can-do protocol, and sees WS-* as being overcomplicated and requiring endless maintenance.Hi there. My name’s Rusty, and I’m an air conditioning tech. I’m not a rocket scientist, but I know how to wield an electronic screwdriver and recharge the freon in a unit. Lately I’ve taken a job with Roy’s Environmental Systems Technology. It sounds impressive, but really it’s just another air conditioning and heating company, nothing cutting edge, nothing fancy. We mostly just call it REST.
Lately, however, we’ve been losing business to a newcomer in town, and I’m not quite sure why. A couple of years ago Water Supply-Strategic Tactical Air Recycling (WS-STAR) opened up a branch in our town. WS-* (as my IM crazy kids would type) came about from the merger of Secure Operations Air and Power (SOAP) with Expert Machine Lubrication: Radiators, Power, and Cooling (XML-RPC). Highly enjoyable reading, and worth some thought when one is considering WS-* against REST - although it should be added that sometimes, you really do want the full WS-* stack, despite its potential complexity.
|
|
|
Message #208468
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
REST vs. WS-*, a Parable
WS-* presumes SOAP and involves providing many declarative services to an internet messaging environment. I would be interested in seeing scenarios where these things are also accomplished using REST (e.g. transactions, security, policy, etc.)
|
|
|
Message #208471
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
REST vs. WS-*, a Parable
WS-* presumes SOAP and involves providing many declarative services to an internet messaging environment. I would be interested in seeing scenarios where these things are also accomplished using REST (e.g. transactions, security, policy, etc.)
It would also be interesting to see those REST scenarios where the implementations are even remotely interoperable with other implementations.
|
|
|
Message #208472
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
REST vs. WS-*, a Parable
Exactly. There are no standards for doing these things (represented by the plethora of WS-* standards) in REST, so if the need does arise, what do you do?
SOAP document/literal is very simple so the difference between doing that and schema defined REST is minor, but when you need to add additional functionality, SOAP's extensibility is there to help you. (BTW, WSDL is not required for SOAP so don't whine about that. WSDL is a nice thing to have for what it does.)
For example, WS-Security lets me do SAML in a transport independent way - over MoM, over HTTP, over sockets, SMTP, etc. WS-* standards, such as WS-ReliableMessaging, are not there for me to use directly but for my vendors to use with each other to achieve inter-operability. I could use it directly, but I'd rather let my MoM/ESB vendor deal with it. In fact, most if not all of what goes into a SOAP header (which is itself optional) is really intended to be dealt with by your middleware vendors, not the application programmers. At least that is where it is supposed to be heading.
Personally I think the whole WS-* bit has gone way too far, but then that's because a lot of what I see as unnecessary is what I don't need on the edges. Nevertheless, the existance of an unnecessary (to me) WS-* standard really doesn't affect me because I don't have to use it.
The point is that if you compare what it takes to accomplish the exact same things in SOAP versus another XML messaging scheme, SOAP is never much harder and is often (when complex things and interoperability are in play) much easier to use.
|
|
|
Message #208478
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
It's like he's comparing OOP to Java
REST is a model. WS-* is a standard for communication over a transport. Can WS-* fit the REST architecture model? I would say it can.
Looking at Flickr, which uses the REST model, I'd say that they've simplified the interface to their underlying repository. How difficult is it to consume there service using Java? From my vantage point, you have to hand code each request and parse each response which is tedious IMO. If they provided a XSD for their document types, I could leverage a tool like XMLBeans or JAXB and get on to coding the requests. If they could provide a WSDL (which they can't because of the way REST urls differ with the way WebService endpoints are modeled...not a good or bad thing...just different) then I could use WSDL to Java tool to create my client API. If they used SAML for security assertions, I could an existing library, like WSS4J, to help manage security in my application. Flickr doesn't do this but that's they're choice and to there credit it is rare you find an enterprise developer with their tools in hand (all open source btw) that wants to interface with a consumer service.
So REST vs. WS-* isn't the issue. It's about choosing standards to communicate and picking a model that works. Can REST and WS-* coexist...absolutely. Do we need to divide developers on a non issue...no.
-Noah
|
|
|
Message #208481
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
REST vs. WS-*, a Parable
Reading the above replies I started doubting where I lived. On the Moon? Oh no, not at all. Looking around, I'm still here on the lovely Earth ;)
There were so many 'if's and 'in the future', and so on, that those guys need to be brought back to this reality.
|
|
|
Message #208483
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
It's like he's comparing OOP to Java
So REST vs. WS-* isn't the issue. It's about choosing standards to communicate and picking a model that works. Can REST and WS-* coexist...absolutely. Do we need to divide developers on a non issue...no.-Noah
Well it is an issue because there is no standard for using WS-* in REST. There is no standard payload format for REST. As you say, its a style. Without some standards you don't have a vendor independent, interoperable way to use WS-*. SOAP provides a place to put the WS-* data and a model for processing it. Technically you could use a SOAP payload in a REST style, but I don't think that is what most people have in mind when they draw the distinction.
|
|
|
Message #208485
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
REST vs. WS-*, a Parable
If you read the article you will see that its not WSDL that the post criticizes, its the tooling. The tooling is pretty bad I agree. And that is a problem if you are trying to harness the power of WSDL, but the problem is not WSDL itself.
WSDL allows me to define service interfaces in an implementation independent way and define multiple transports and protocols for accessing it. It allows me to harness the capabilities of ESBs, services management products, governance products, etc. There is no good substitute in for a large enterprise trying to integrate with SOA.
|
|
|
Message #208498
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
REST vs. WS-*, a Parable
The SOAP way is not an easy way. Yes, you can develop web services without a WSDL just like you can write code without commenting it. And anyone who has to consume your WSDL-less service now has to write a ton of code by hand because you were too lazy. But, hey, SOAP is easy right? I know, your one of those sick types that have no problem sitting behind a computer and typing all day 24-7 so writing a few thousand lines of code is fun to you. Screw that. REST is easy like Sunday morning, so why waste the time with the WS-* mess.
|
|
|
Message #208510
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
REST vs. WS-*, a Parable
The SOAP way is not an easy way. Yes, you can develop web services without a WSDL just like you can write code without commenting it. And anyone who has to consume your WSDL-less service now has to write a ton of code by hand because you were too lazy. But, hey, SOAP is easy right? I know, your one of those sick types that have no problem sitting behind a computer and typing all day 24-7 so writing a few thousand lines of code is fun to you. Screw that. REST is easy like Sunday morning, so why waste the time with the WS-* mess.
Well like I said, you use what you need. Tell me, what is the REST alternative to WSDL (which is not part of SOAP and can describe REST services too)? If you need it or the equivalent for SOAP, you need it for REST. What is the REST equivalent of WS-Security, WS-Addressing, WS-ReliableMessaging, etc., etc.? If you need their functionality for SOAP you would also need it for REST. Your business requirements (security, routing, guaranteed delivery) don't change because of the style you choose.
Remember I'm talking about SOAP document/literal. That's the same plain XML data you might use in REST wrapped in an <body/> wrapped in and <envelope/>. No RPC/encoded, just a plain XML message. So, how do you accomplish all these things in REST? And if you have a solution that doesn't involve a lot of extra coding, how inter-operable is it?
|
|
|
Message #208536
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
REST vs. WS-*, a Parable
Reading the above replies I started doubting where I lived. On the Moon? Oh no, not at all. Looking around, I'm still here on the lovely Earth ;)There were so many 'if's and 'in the future', and so on, that those guys need to be brought back to this reality.
Exactly!
Or rather - 'I have a 100 kg hammer, now I need to find me a nail'.
This collective mass hypnosis with SOAP-SOA-ESB reminds me of EJBs mania five years ago except that this one is just worst.
|
|
|
Message #208548
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
REST vs. WS-*, a Parable
WSDL allows me to define service interfaces in an implementation independent way and define multiple transports and protocols for accessing it. So does IDL, ODL,and even COBOLs copybook!
WSDL is unnecessary overcomplicated which is obvious when we look at that ISBN WSDL example. Please read the thread too, not just the article.
It allows me to harness the capabilities of ESBs, services management products, governance products, etc. I would say it is supposed to ....
There is no good substitute in for a large enterprise trying to integrate with SOA. What does it mean for Pete's sake?! O the power of brainwashing!
There is no SOA product, standard, etc. that is called SOA. SOA is the newest marketing term to label what people
were doing when tried to integrate systems into something bigger. SOA simply put is just a mindset. Ans services not NOT have to be XML based. It is better for them not to be IMO.
|
|
|
Message #208554
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
REST alternative to WSDL
Tell me, what is the REST alternative to WSDL (which is not part of SOAP and can describe REST services too)? There are several propositions including:<br/>
Web Resource Description Language (WRDL)<br/>
Web Application Description Language (WADL)<br/>
Simple Message Exchange Descriptor (SMEX-D)<br/>
And also a standardization discussion at the W3C.
What is the REST equivalent of WS-Security HTTP authentication and SSL.
WS-Addressing The HTTP referrer header works well, additional URI can be provided in the URI (wsa:messageID), in the message or in the URI parameters (wsa:from URI, wsa:to URI) if really needed. Not sure what is the actual business need here.
WS-ReliableMessaging Similar patterns are available. Most of the time you want to be sure that your message arrived. In REST you can simply start a "transaction" which is identified by a unique URI, then use this URI to post your message. This returns an HTTP success status if the request completed with no problem. If the communication was lost before getting this status, you can simply get the status of the transaction by getting the transaction representation at the unique URI. If it actually failed, you can abort/start a new one.
Regards,
Jerome Louvel
Restlet, a REST framework for Java
|
|
|
Message #208570
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
REST vs. WS-*, a Parable
If you read the article you will see that its not WSDL that the post criticizes, its the tooling. The tooling is pretty bad I agree. And that is a problem if you are trying to harness the power of WSDL, but the problem is not WSDL itself. WSDL allows me to define service interfaces in an implementation independent way and define multiple transports and protocols for accessing it. It allows me to harness the capabilities of ESBs, services management products, governance products, etc. There is no good substitute in for a large enterprise trying to integrate with SOA. Oh yes,
there is a huge problem with WSDL itself !!!
Take a look at a much more precise and better analysis made by Michi Henning at www.zeroc.com
In short, what I find rather "uncomfortable" is exactly the specification of the endpoints in WSDL.
It is totally crazy.
What if I have an identical service (in terms of operations) provided by multiple independent providers ?
Is UDDI the answer ?
Really I need that monster to reference 2 endpoints (think about testing enviroment) ?
OK, I am oldie, but I prefer CORBA style, with IDL containing only the interface definitions and simple
string parsing for endpoint identification.
Guido
|
|
|
Message #208585
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
REST vs. WS-*, a Parable
Take a look at a much more precise and better analysis made by Michi Henning at www.zeroc.com
Where exactly is the article in zeroc's page?
|
|
|
Message #208587
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
REST alternative to WSDL
also you might want to have a look at this:http://xins.sourceforge.net/ Rather than being an alternative to WSDL, isn't XINS just a tool which (among other things) can generate a WSDL? How is it a "REST alternative to WSDL"? Please explain. In your explanation please address how this tool deals with
Non-Java endpoints
Multiple transports for accessing a Service operation
Message formats
Multiple service access protocols - not just SOAP
- All without using WSDL. Please tell me how. I don't see anything out there that substitutes for WSDL.
|
|
|
Message #208589
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
REST alternative to WSDL
Thanks for this response, Jerome. It's really nice to see some specific information given as to how REST could subsume WS-*. But I see the following issues:
1.) These alternatives to WSDL either look very similar to WSDL since you have to descripe the method signature somehow or look extremely incomplete (like someone's blog entry).
2.) Using HTTP auth and SSL for security won't fly in a true internet environment especially in the case of service composition.
3.) The business need of WS-Addressing is usually coming from the other specifications that utilize it, e.g. it serves as plumbing for WS-Transactions and other specs. However, I have encountered businesses who want to use it for say versioning of services. I don't see how your solution would support this.
4.) Suppose we have a scenario of a web server forwarding requests to an application server which invokes web services. The RM approach you describe would return success even if the application server were down and the message never reached the actual web service.
I would predict that since these core WS-* specs are being codified that we will see vast improvement in tooling since vendors don't usually commit much effort to areas that are still in flux.
|
|
|
Message #208598
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
REST alternative to WSDL
HTTP and SSL - WS-Security is not for encryption, but I can use SAML with HTTP. Unfortunately SAML represents only a subset of what WS-Security does. Its not a substitute.
As an alternative to WS-ReliableMessaging you say that there are "patterns available". That is all fine and good, but there are patterns available or alternate solutions to any standard you can name. The problem is that these alternatives are not formal standards. In which case you are basically saying that if I use REST services and need the kind of functionality supported by the WS-* stacks that I will need to negotiate standards with every client I deal with. I think the idea of having standards was to avoid that situation because its the very costly hell we are trying to get out of.
|
|
|
Message #208612
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
REST vs. WS-*, a Parable
I worked extensively with CORBA in the past and I'm sure he (ICE) has some valid points here but one that I firmly disagree with is:
"SOAP is a very basic protocol, with no support for object-oriented development of distributed applications."
Why do we want to use OO to develop distribution? Developing services themselves using OO makes sense but the integration should be based on Orchestration in any SOA whether web services are used or not. OO just introduces tight coupling via its inheritance and relationship mechnanisms.
|
|
|
Message #208616
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
REST alternative to WSDL
Rather than being an alternative to WSDL, isn't XINS just a tool which (among other things) can generate a WSDL? How is it a "REST alternative to WSDL"? Please explain. In your explanation please address how this tool deals with
Non-Java endpoints
Multiple transports for accessing a Service operation
Message formatsMultiple service access protocols - not just SOAP- All without using WSDL. Please tell me how. I don't see anything out there that substitutes for WSDL.
i am not involved with the project so maybe the stuff below is not 100% correct.
It gives you the choice - that is the nice feature.
The services are defined in a proprietary -but simple- xml format. Yes - as you said - it includes tools to generate WSDL file from this format (also the api classes, tests etc.).
You can then access the same service either via REST, XML-RPC or SOAP. The transport is limited to HTTP(S) though.
also you might even see the definition format of xins as a simple (i am not saying the it gives you the full feature set that all WS-* specs offer) replacement for WSDL - the code generators are xslt templates. So just write a template for your favorite programming language and you have the client api - which you then can distribute to whatever clients you have. OR let the client generate whatever they want from the wsdl.
But something else:
There is also another nice feature of REST which hasn't been mention yet. Again only applies for certain use cases though. REST is cacheable by any standard HTTP cache (mod_cache, squid etc. pp).
One more note on security:
if you really need very tide security of your service i still prefer to that in the networking layer (vpn,ip restrictions etc).
Eike
|
|
|
Message #208618
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
REST vs. WS-*, a Parable
"Why do we want to use OO to develop distribution? Developing services themselves using OO makes sense but the integration should be based on Orchestration in any SOA whether web services are used or not. OO just introduces tight coupling via its inheritance and relationship mechnanisms.
There are two camps,
one says: you do not need this because you should not be doing this;
and the second says: there is the platform that does all you might need in this particular domain;
SOAP and M$ ideology are vivid examples on the camp one, and Unix and CORBA clearly belong to the camp two.
Answering your question: because for certain scenarios it is the best thing to do. Speaking from personal experience: at the end of last century I was involved in the CORBA project and we have started with basic things, but when our demand grew we just discovered that CORBA has already thought about that and there is implementation. That was very cool and enjoyable experience.
Not so with any of the SOAP and XML projects I was involved or observed: as the demand grew it lead to the Oh s-it! moments when team realized that a need to amend those crippled XML based solution with something custom, reinvent the wheel basically. Lets face it: the whole SOAP opera is about reinventing CORBA infrastructure and services on the XML basis.
|
|
|
Message #208631
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
POX-IDL (in XINS) an alternative to WSDL ?
Rather than being an alternative to WSDL, isn't XINS just a tool which (among other things) can generate a WSDL? It is a framework for distributed applications. Like each framework it has some constraints:
- HTTP-based communication
- RPC-style server-side implementations
- Java-based server-side implementations
It combines the following (from http://en.wikipedia.org/wiki/XINS ):
1. An XML-based specification format (called POX-IDL)
2. A POX-style RPC protocol (called POX-RPC)
3. Tool for generating human-readable documentation, WSDL, stubs, WAR files, etc.
4. A Log4J-based technology for logging (called Logdoc), offering a specification format, internationalization of log messages, generation of HTML documentation and generation of code.
5. A Java client library for POX-RPC.
6. A server-side container for Java-based XINS API implementations
For some more background, read this PDF:
http://xins.sourceforge.net/frameworks_and_xins.pdfNon-Java endpoints
Multiple transports for accessing a Service operation
Message formats
Multiple service access protocols - not just SOAP Although POX-RPC is XINS-specific, XINS supports various other protocols, including SOAP and XML-RPC. Also, XINS allows the addition of new protocols. This requires the implementation of a subclass of class CustomCallingConvention.
So interoperability for clients is not an issue. It can even be called from browsers. Try this test form:
http://xins.sf.net/demo/specdocs/myproject/MyFunction-testform.htmlAll without using WSDL. Please tell me how. Indeed, all without WSDL. Instead, it uses a very simple format we call POX-IDL. The problem with it is that it's contained within the XINS project and it's not documented independently. But we are considering splitting XINS in several separate components, because some of them have a use on their own, such as Logdoc:
http://xins.sourceforge.net/logdoc/1.4.0/server/index.html
Lastly, here's one of the DTDs for POX-IDL:
http://xins.sourceforge.net/dtd/function_1_4.dtd
Have a look at the XINS Primer if you want some more examples.
|
|
|
Message #208646
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
REST vs. WS-*, a Parable
Read the parable and it was light hearted and fun. Faced with WS-* who wouldn't crave for something much simpler? I did, but after reading Roy fieldings paper and asking pertinent questions on the REST discussion group, I concluded that for the type of things I want to do REST just isn't it.
I got the same feeling as the guy whose post said he needed to check that he was on earth. Most of the posts in this thread I just don't recognise. Doing REST with Soap How? What ever happened to the uniform connector constraint?
REST does exactly what it says on the box: REpresentational State Transfer - moving mostly static data around using a uniform connector (HTTP GET, PUT, POST etc).
So what happens when you want to do transactions? Well there's no COMMIT, and no ROLLBACK. As for Objects well forget encapsulation, and behaviour other than GET, PUT etc.
So what is this discussion all about? Has the level of debate on TSS come to this?
Paul.
|
|
|
Message #208648
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
REST vs. WS-*, a Parable
I worked extensively with CORBA in the past and I'm sure he (ICE) has some valid points here but one that I firmly disagree with is: "SOAP is a very basic protocol, with no support for object-oriented development of distributed applications."Why do we want to use OO to develop distribution? Developing services themselves using OO makes sense but the integration should be based on Orchestration in any SOA whether web services are used or not. OO just introduces tight coupling via its inheritance and relationship mechnanisms. Why do you disagree ?
That sentence is plain true.
An it not in contrast with your point.
Not all the distributed applications, or not all pieces, can be built as you say.
More, I don't think OO introduces tightly coupling per se, nor SOA is always loosely coopling.
I don't see how OO inheritance implies tightly coupling: if an objetc is-a something, thne IS that something, you like or not.
There is no mandatory relationship mechanism in OO approach.
It's a matter of design.
Guido
|
|
|
Message #208649
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
REST vs. WS-*, a Parable
...Lets face it: the whole SOAP opera is about reinventing CORBA infrastructure and services on the XML basis. Clap, clap
+1
Guido.
|
|
|
Message #208653
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
REST vs. WS-*, a Parable
...Lets face it: the whole SOAP opera is about reinventing CORBA infrastructure and services on the XML basis. Clap, clap+1Guido.
SOAP, in large part, is nothing but a marketing gimmic. Who wants to hear about CORBA/ICE when you have servers to sell; think of MS, IBM, SUN, HP... They all want to sell you servers and applications that do XML. XML is big, fat, and slow. Bingo, you need hordes of servers just to do simple XML (de)serialization.
|
|
|
Message #208670
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: REST vs. WS-*, a Parable
Developing services themselves using OO makes sense but the integration should be based on Orchestration in any SOA whether web services are used or not. OO just introduces tight coupling via its inheritance and relationship mechnanisms.
Don't confuse OO and inheritance. This is a common misconception. Classes and Inheritence is just one way to define object implementation, some OO languages do not have classes at all (e.g. the Self language and JavaScript) and dynamic OO languages like Smalltalk have the good sense not to couple objects through explicit declarations of Type (Class) every where.
OO is about reducing coupling and increasing cohesion (effective chunking), the thing OO brings to the table is encapsulation (I do not need to know your state to use your service). Dynamic OO is the ultimate loosely coupled, message based SOA. The problem is that so called OO languages derived from C++ (Java and C#) just aren't implemented that way.
Paul.
|
|
|
Message #208692
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: REST vs. WS-*, a Parable
SOAP, in large part, is nothing but a marketing gimmic. Who wants to hear about CORBA/ICE when you have servers to sell; think of MS, IBM, SUN, HP... They all want to sell you servers and applications that do XML. XML is big, fat, and slow. Bingo, you need hordes of servers just to do simple XML (de)serialization.
Actually, XML is not very heavy in itself. But add meta-data in the requests and responses, references to external files (XML Schema) etc. and you've got one big bloated monster :-)
|
|
|
Message #208724
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: REST vs. WS-*, a Parable
SOAP, in large part, is nothing but a marketing gimmic. Who wants to hear about CORBA/ICE when you have servers to sell; think of MS, IBM, SUN, HP... They all want to sell you servers and applications that do XML. XML is big, fat, and slow. Bingo, you need hordes of servers just to do simple XML (de)serialization.
Actually, XML is not very heavy in itself. But add meta-data in the requests and responses, references to external files (XML Schema) etc. and you've got one big bloated monster :-)
I agree SOAP is terrible. But if SOAP is so bad why has Sun (or should I say the JCP?) adopted it?
Paul.
|
|
|
Message #208726
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: REST vs. WS-*, a Parable
...(effective chunking)...
Don't you mean (selective clunking)?
|
|
|
Message #208743
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: REST vs. WS-*, a Parable
OO is about relationships and abstractions be they inheritance, association, composition or aggregation. They all introduce dependencies that are undesirable in distributed systems. Orchestrators represent flow charts (with some additional longer running "task" support), and they are completely agnostic to the services they are orchestrating. So there are no relationships between services, they are completely decoupled. As I said before, an OO approach can be used to develop the services and even the underlying framework of the orchestration mechnanism but a different type of analysis is required for the SOA itself.
|
|
|
Message #208752
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: REST vs. WS-*, a Parable
OO is about relationships and abstractions be they inheritance, association, composition or aggregation. They all introduce dependencies that are undesirable in distributed systems.
?????
OO is this ?
OK, tonight I will read Rumbaugh again, but I don't think
I will find your answers.
Orchestrators represent flow charts (with some additional longer running "task" support), and they are completely agnostic to the services they are orchestrating. So there are no relationships between services, they are completely decoupled. As I said before, an OO approach can be used to develop the services and even the underlying framework of the orchestration mechnanism but a different type of analysis is required for the SOA itself.
As I said before, is a matter of design of your distributed
object system.
Object-orientation does not enforce any of your concerns.
I really don't see how inheritance can cause you troubles.
If an element of the domain (i.e. an object), has some commonalities with other elements of the domains you have candidates for superclasses from which you can specialize your leaf services.
It's a matter of life, things (objects) ARE, you like or not.
Guido.
|
|
|
Message #208753
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: REST vs. WS-*, a Parable
I agree SOAP is terrible. But if SOAP is so bad why has Sun (or should I say the JCP?) adopted it?
Paul.
Well, lets see...
Who is in the JCP? - Software Vendors
And how do they make money? - Selling Software and consulting services and computers.
Do they have interest in supporting something that will just work? ...... Your guess?
|
|
|
Message #208759
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: REST vs. WS-*, a Parable
OO is about relationships and abstractions be they inheritance, association, composition or aggregation. They all introduce dependencies that are undesirable in distributed systems. Orchestrators represent flow charts (with some additional longer running "task" support), and they are completely agnostic to the services they are orchestrating. So there are no relationships between services, they are completely decoupled. As I said before, an OO approach can be used to develop the services and even the underlying framework of the orchestration mechnanism but a different type of analysis is required for the SOA itself.
Hi,
I Agree with your view on coupling, but whos definition of OO are you using?
Sun have been responsible for more than one OO language. Take a look at this one:
http://research.sun.com/self/language.html
No classes, no inheritance, no static type coupling, just messaging and object encapsulation.
C++ and it's offspring have given OO a bad name. I'm just trying to set the record straight. There is so much mis-communication in our industry (read marketing), that many good ideas been consigned to history or have been re-inveted in a weaker form. Pure message based OO offers everything you can get from SOA and a lot more.
Paul.
|
|
|
| New content on TheServerSide.comNew content on TheServerSide.comNew content on TheServerSide.com |
|
|
Reza Rahman explores the features of the proposed JSR 299, Contexts and Dependency Injection for Java EE (CDI). When approved, it promises to be a key feature of Java EE 6.
(November 2, Article)
SAML is an XML-based standard for exchanging authentication and authorization data between security domains. The single most important problem that SAML was created to solve is the Web browser Single Sign-On problem. Many organizations are debating whether to stay with version 1.1 or move to 2.0. This article makes observations about both options.
(September 28, Article)
Joe Ottinger takes a look at how people learn, and applies it to the practice of programming. He notes that understanding how people learn is an essential part of working in a programming team.
(September 22, Article)
Stephen Maryka gave us an article about the Asynchronous Web and posed a number of questions that get examined like an approach to delivering Asynchronous Web capabilities through extensions to existing Java EE technologies.
(July 14, Article)
JavaServer Faces Flex goal is to provide users capability in creating standard Flex components, part of flexSDK which is open sourced through MPL license, as normal JSF components. This article by Ji Hoon Kim will provide an overview of creating a simple multilingual JSF page consisting of JSF Flex tags.
(June 29, Article)
In this session Jeff explores the key characteristics of successful SOA projects. He covers some of the patterns, and anti-patterns, tool sets, and strategies that he himself learned the hard way. Last, he provides a strategy and blueprint for achieving a high likelihood of success in your SOA project.
(June 23, Tech Talk)
Ari Zilka, CTO of Terracotta, Inc., talks about the new features in Terracotta 3.1, announced during JavaOne and available now.
(June 15, Tech Talk)
In this Tech Talk, Josh Long explores an integration challenge using Spring Integration and walks through the implementation, employing and expanding on the basic patterns of Enterprise Application Integration to tie together components into a function integration solution, and then demonstrates how Spring Integration helps address the integration requirements.
(June 15, Tech Talk)
In this Tech Talk, David Geary teaches you: The basics of Google Web Toolkit; How to implement Ajax-enabled applications in Java; Internationalization; Hooking into the browser history mechanism; Remote procedure calls.
(June 4, Tech Talk)
Jon Kern discusses the best architecture/technical solutions and ensure that they are repeated by all developers. By tackling the architecture up-front in a serial manner, subsequent parallel development will be much more manageable and predictable.
(May 28, Tech Talk)
This keynote describes the frustrations of modern knowledge workers in their quest to actually get some work done, and solutions for how to guard yourself against all those distractions. Neal Ford talks about environments, coding, acceleration, automation, and avoiding repetition as ways to defeat the misguided attempts to sap your ability to produce good work.
(May 26, Tech Talk)
Gil demonstrates how new, aggressive uses of already abundant compute capacity by common applications offer competitive value for application designers.
(May 21, Tech Talk)
Chris Keene introduces WaveMaker as a new way to automate the ability to generate Hibernate classes in order to more quickly bring OR mapping into an application.
(May 19, Article)
In this session Nati Shalom demonstrates how to take a standard Java EE web application and scale it out or down dynamically without changes to the application code. Seeing as most web applications are over-provisioned to meet infrequent peak loads, this is a dramatic change because it enables growing your application as needed, when needed, without paying for unutilized resources.
(May 19, Tech Talk)
Mastering EJB was one of the original and most influential EJB books in the industry. Mastering EJB III now returns with two new expert co-authors, updated for EJB 2.1 and 30% new chapters including security, integration, best practices, open source, and more.
(Book PDF Download)
The Application Server Matrix is a detailed listing of J2EE vendors and their application server products, with information on latest version numbers, J2EE spec support and licensing, pricing, platform support, and links to product downloads and reviews.
(Application Server Comparison Matrix)
|
|
