From: "Vince M. Clark" <[email protected]>
There will be an ESB, probably ServiceMix in our enterprise architecture. That
will be used to communicate with backend
applications like Oracle Financials, a warehouse system, etc.
Yes, sounds like the most desirable solution nowadays
We are using OFBiz and a couple of other applications that handle e-commerce,
then PHP at the web tier for presentation. Each of
our ecommerce applications must be accessible via restful web services. Each
has their own way of doing it, for example one of the
apps is .NET.
We have prototyped Axis with OFBiz. I would be fine with using the service
engine directly, but from everything I have read in the
documentation and ML there are limitations. And since Axis was a documented
alternative that is the approach we took.
Yes, it may be simpler than using an ESB if you have only a couple, or say a
dozen, of services to link. As you will using an ESB
for other purposes you should be able to see if it's not a good solution also
with OFBiz in your case. The reason is that OFBiz has
a SOA and EDA architecture internally and an ESB extends this architecture
outside of OFBiz. I don't say an ESB is an universal
solution, but it's a step...
So the architecture is like this:
Web - PHP
E-Commerce - OFBiz, .NET, Endeca, a few other custom apps.
Backend - Oracle, warehouse system, retail system, etc.
It seems that you have already your architecture. And I will not question it.
We are using lighter weight web service technologies between PHP and the
e-commerce apps. With OFBiz we need to do more than pass
around documents. We will be conducting transactions. For example the web tier
will call OFBiz to create a shopping cart and take
a customer through checkout, see order history, manage profile, etc. So I question
the statement that " all you really need is
already in OFBiz."
Héhé, don't forget context : "in most cases" and "Notably, but not only, when you
need to speak between OFBiz instances". Also this
does not mean that OFBiz is the ultimate soltution for all Enterprise level
problems, but it's a good brick, isn'it ? OFBiz has
still to go, as David suggested below using OAGIS or UBL for instance. Using an ESB you can focus on this level forgetting protocols
level.
One point with ServiceMix is that it is JBI compliant (actually it's a complete
JBI implementation). JBI defines a normalised bus
for messages exchange (NMR : Normalized Message Router). All there is XML. I
believe it simplifies things, that's all...
If you are interested by JBI you may found all what you need here
http://servicemix.apache.org/articles.html
Jacques
From: "Jacques Le Roux" <[email protected]>
To: [email protected]
Sent: Wednesday, March 11, 2009 2:51:35 AM (GMT-0600) America/Chicago
Subject: Re: restful web services
This is also why I spoke about ESB, particularly ServiceMix (which happends to
be an Apache project ;o).
But in most cases, as David explained, all you need is already in OFBiz.
Notably, but not only, when you need to speak between
OFBiz
instances.
On the other hand if you regularly need to speak with other applications, then,
IMO, you should really care about ESBs...
A good book I'd recommend http://www.manning.com/rademakers/. There are also a
lot of free informations at ServiceMix site...
Jacques
From: "David E Jones" <[email protected]>
OAGIS message are just XML files, and can be sent over whatever transport
protocol. The code in OFBiz sends them via HTTPS, which
is the most common form of synchronous transfer. They are written to get
asynchronous responses though, so doing it via a
message broker would work well too.
In general they are not SOAP, but you could call them REST using the lame/common meaning
of it. Really they are more of the "POX"
style, ie "Plain Old XML".
This sort of thing makes a lot more business sense, IMO, than something that
tries to do object mapping and such like SOAP is
mostly meant for (and really hard to use without those sorts of tools). In
OFBiz we just make the messages with a template
(using FTL to generate XML, just like we use it to generate HTML), and then
have Java code to consume the XML coming in (though
I'd like to extend simple methods to do that).
So, there is nothing to build for this... ie the tools are already in place and
examples of them in various places, especially
the oagis component.
Stepping back a little bit... when you're talking about integration it mostly
depends on the constraints of the other system. If
there are no constraints then I'd recommend focusing on message format
standards (like OAGIS or UBL) instead of transport
protocol and formatting standards like SOAP, REST, etc. You can write stuff
that conforms to those lower level standards all you
want, but significant work will still be required to use those messages with
other systems that use the same technologies
because the data structures, ie message format, are totally different (and
possibly not reconcilable without encumbering and
limiting the business).
-David
On Mar 10, 2009, at 1:40 PM, Vince M. Clark wrote:
Very helpful, thank you.
As you may have noticed from recent threads we have been working with Axis. To
date we have only used SOAP. Our client just
informed us that they want to standardize on REST, which seems easy enough to
do with Axis. As we started down this path we
came across the blog post I referenced claiming "How NOT to do RESTful web
services" which raised some concerns.
Interesting that you mentioned OAGIS, as our client also stated that they want
to standardize on this for transporting documents
across systems. So I guess the question is, what is our best path? Continue
with Axis, or make/fund/wait for changes to the
OFBiz service engine. Either way I intend to leverage what has already been
established in the OAGIS component.
----- Original Message -----
From: "David E Jones" <[email protected]>
To: [email protected]
Sent: Tuesday, March 10, 2009 2:27:44 PM (GMT-0600) America/Chicago
Subject: Re: restful web services
Yes, the term "REST" and it's cousin "REST-ful" are some of my least
favorite these days. They were watered down and misinterpreted from
day 1. The concept of them has been around for years, but people
started applying it to everything that isn't SOAP, which is just silly.
The thing to keep in mind with REST that most tools ignore is the
separation of verbs and nouns. The "nouns" are addressable resources
and verbs are used to interact with the nouns... with various verbs
mapped to the exist HTTP request type (ie GET, POST, etc).
I like the idea of separation of verbs and nouns (which OAGIS does a
decent job of, and with a set of nouns that is much more business
friendly), but most of the REST ideas are rather... limiting. They are
fine for CrUD types of operations, but not much more given the limited
set of available verbs.
Still, the theory is somewhat irrelevant since the common usage of the
term "REST" has been reduced to near meaningless. Sometimes it seems
that people like to seem fancy, but all too often can live up to the
fanciness they created for themselves.
Anyway, for OFBiz the main concept from REST and OAGIS that we might
consider implementing is support in the service engine for a
separation of verbs and nouns. We have common service naming patterns
that we use in a de-facto sort of way, like the service
"createProduct" which has the noun "Product" and the verb "create". It
would be cool if the service definition supported this sort of 2-part
naming, and with a way to associate nouns to entities when applicable
(and of course nouns could be things other than entities, like XML
schemas or whatever).
I'm not sure that is helpful commentary, but there are some thoughts
on the issue anyway (which I've been following with agonized
fascination for a while).
-David
On Mar 10, 2009, at 12:41 PM, Vince M. Clark wrote:
This blog is arguing that Axis2 doesn't do true RESTful web
services. I'm interested in thoughts and comments from the community.
http://atmanes.blogspot.com/2007/06/how-not-to-do-restful-web-services.html
