[
Lists Home |
Date Index |
Thread Index
]
Michael Brennan wrote:
>
>...
> I was trying to explicitly present the view of a business developer who is
> implementing business logic (in a CRM or ERP system, for example), and needs
> to expose functionality via a web service. To me, that business logic is the
> "application". And to me, I will need design patterns and models to guide my
> design that I can relate back to the business functionality I am writing.
>
> The web service is just one portion of my design effort, and is not even my
> primary focus. It is just an interface.
If you want to take that point of view, and can get away with it, then
there are a variety of technologies that are sufficient for business
integration. I've used CORBA, DCOM and even XML-RPC in the mode you
discuss.
But consider that for the last several years, programmers have spent a
massive amount of effort figuring out how to make a "web interface" to
their software. Web application frameworks, J2EE, ASP, PHP, etc. etc.
Part of this is because people have spent the last few years remapping
their problem domains into the REST model. They don't know that this is
what they are doing but to get the Web to work at all you have very
little choice. In particular, you have to figure out how to give URIs to
anything you want people to be able to reference, bookmark, hyperlink,
etc. You have to understand the distinction between GET and POST.
Putting a web services "interface" on your business logic is roughly as
challenging. It requires thinking about the business from the outside
in. You need to think about extensibility. You need to find relevant
standards. You don't want to innovate if you don't have to, because that
will make your partner's integration harder. There are a ton of
scalability and security constraints that are much harder to solve than
those within the organization.
> ... It sounded to me like you were
> trivializing that side of things and saying the web service is all that
> matters and all that needs to be considered, and that the entire design
> effort of such an application can be cast in terms of an extension to HTTP.
No. Just that any coarse-grained, machine-to-machine *protocol* can be
cast as an extension to HTTP.
> Basically, it sounded to me like you were trivializing 99% of the sort of
> work I've done in my career. That's why I took such strong offense.
I understand and apologize for the misunderstanding. We had some
terminological disconnects.
Paul Prescod
|
