81–90 of 92 posts
It's easy to rant, but hard to come up with a viable alternative, that encompasses the same scope. XML-schema and WSDL are mocked as an aside, but I dare you to provide me a REST alternative for those, as standardized as those. For all the horror stories, I have used Java to interact with a C# webservice without any pain, including WS-Adressing. The WSDL and XML-schema were a godsend compared to the earlier spec. Lik…
Earlier quoted context omitted.
I'm being asked to create webservices so other developers don't do direct database access and their stuff wont break when things change. How do you manage that?
Designing an API is a skill in itself, but I think rule 1 is "Don't use SOAP" JSON over REST seems to be flavour of the month FWIW.
A key point the writer alludes to (and an IMPORTANT one) is that SOAP was hyped by tool vendors because it game them something to SELL you. There's really nothing to SELL with RESTful stuff, it just works and is inherent to the internet, therefore tool vendors aren't exactly pumped up about selling you anything.
Earlier quoted context omitted.
Seriously? I'm actually surprised that anyone would find SOAP complex. I see it as incredibly simplistic to implement. Are you really saying you avoid web services because you don't understand SOAP? I've done them in both .NET and Java many times.
Have you had different SOAP stacks talking to each other? The case of having identical SOAP implementations at either end (eg .NET 2.0 .NET 2.0, Java w/ Axis 1.4 Java w/ Axis 1.4) is the one scenario where SOAP works as you'd hope.
Ha ha! I must remember this put-down - it could be used in so many contexts :)
Love it. However at least SOAP is a spec and generally works. REST is an architectural style there is no spec, just a idea! Added to that most folk also only build REST-like services. Implementing a client for REST based services often requires a bunch of (generally simple) coding which takes time and is error prone. Also pure REST is really good for building data access/CRUD services but makes it hard to build RPC t…
Earlier quoted context omitted.
I'm being asked to create webservices so other developers don't do direct database access and their stuff wont break when things change. How do you manage that?
You can't, you're being asked the impossible. Think like this, you need to add the compulsory field of PO Number to your invoice table. It wasn't compulsory before. How do you not break everything? It's impossible. Or, even worse; Projects can now have multiple categories. You change your code so all old requests still work, but suddenly half your systems give users the flexibility to add multiple categories and half…
As for error codes, it doesn't seem non trivial to explain why your validation failed.
Earlier quoted context omitted.
I'm being asked to create webservices so other developers don't do direct database access and their stuff wont break when things change. How do you manage that?
One of several great motivations for that approach is that you want the power to refactor the database later without being limited by the fact that you have seven applications from seven different divisions of the company all hooked up to a single schema design. You want to be able to moderate through a business logic layer. Many businesses wind up in this situation by chance, and then have a very painful journey out…
I sited Fowler, thinking _Patterns of Enterprise Application Architecture_. I've checked and was mistaken. He does somewat similar stuff in QueryObject, but I'm thinking of a much higher-level concept.
I'll desccribe the relevant ORM patterns that I'd use. Most of my experience is with Apache Cayenne (which I strongly recommend), and some with Webobjects EOF before that.
This has been interesting to review. I haven't done serious work in either a compiled language or application development for years. It's interesting to come back at with fresh eyes.
= Entity
Your ORM will have tooling that will generate these classes for you from a tool or definition document.
There is a class per table in the schema. Each instance of Entity corresponds to a row of data in a table. Methods for foreign keys return objects for the linked class.
Your application would have classes Person, Organisation, etc.
ent.Person would have a method ((ent.Organistion) toOrganisationEntity()). end.Organistation would have a method ((List) listPersonEntity()). Once you have an entity, the app can find related things via lookup.
Say you had the Organisation object, and wanted to know all the subjects that people for this company were enrolled in. You bounce through the graph. From Organisation you can get to Person, from there to JoinPersonSubject, from there to Subject.
An improvement on this is to have a separate base and application class. Your ORM generates the base class. You generate your app class and have it extend the base class. You put custom logic in the application class.
Example: Cayenne generates com.company.app.ent.base.Person. It has methods corresponding to each column in the person table. You create com.company.app.ent.Person (different package name) and have this extend the base class. You put convenience methods like ((String) getFullname()) in there.
You can then easily regenerate the base class without impacting your custom logic.
= DataAccessObject
(The summary sentence doesn't make much sense until you understand the concept, so I'll explain with example immediately afterwarss.)
Summary: You use a DataAccessObject for getting entrypoints into the graph of data held in the database.
Explanation: In Entity I described an example of bouncing around the graph. Say you had a user in an education system, and they wanted to get a list of all the organistaions associated with their office. You'd use a DAO to do this lookup.
Strangely, these patterns make a powerful coombination. You'd think that you'd need to add a bunch of extern
Your ORM probably won't generate these, but you should abstract them away into distinct classes like this rather than putting static methods in your
DAO functionality is commonly bolted into Entity classes as an afterthought using static methods. Ugly. Awful. Instead, consider DAO to be a distinct pattern, extending from an abstract base classs. The base class constructor will accept the current user as an argument. There will be a method that forms an ORM join between the current user and the
the current user you'd have common functionality such as a join between the
Unlike Entity, there is not a one-to-one mapping between data access objects and tables. You just create them as you need them. There might be an OrganisationDAO that has the query above, and some other queries in it. But then there might be a situation where you're doing a strange mega query across Organisation, Location and SalesTarget that doesn't seem to be specifically associated with any of those tables more than another. Here, you just create a new DAO.
= Session
The user's application session. In this you'll have a single instance of each DataAccessObject. That way your application can do lookups by going session().orgDao().listOrgWithAccountsAtUserOffice().
I feel a bit sad for all those people who worked on SOAP. I assume most of them simply wanted to make the web better and now we all point and laugh at their efforts with the 20/20 vision that only hindsight can allow. Thanks for trying SOAP people, it was a noble effort but it's game over I'm afraid.... oh wait, I just saw on Wikipedia that these were Microsoft people. In that case, screw em. SOAP is wank! YOU'VE WAS…
On the second thought: The same companies made SOAP right after and along with CORBA. Maybe, even the same people. Don't blame Microsoft too much: IBM, Oracle, SAP, BEA - they are all ... equally "good"
I do a lot of Salesforce.com development and the use of SOAP has been the bane of my existence. They have recently introduced a new REST API that will be going GA in the spring. "Dev: What happens if I GET the endpoint’s URL? SG: Don’t know. Using GET is undefined. Dev: Hrrm. And what happens if I move the service to a different endpoint? Do I get a 301 back? SG: No. SOAP doesn’t really use HTTP response codes. Dev:…
My worst memory of SOAP was dealing with an attachments API that required each byte in a byte array to be wrapped in an XML element. You ended up transferring ~10x the size of the file. I suppose gzip would have helped somewhat.
(sorry if by "gzip would have helped" you meant that)