OFBiz › OFBiz - User

restful web services

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

9 messages Options

Vince Clark

restful web services

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

David E Jones-3

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

Vince Clark

Re: restful web services

In reply to this post by Vince Clark

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" <[hidden email]>
To: [hidden email]
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

David E Jones-3

Re: restful web services

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" <[hidden email]>
> To: [hidden email]
> 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
>

Jacques Le Roux

Re: restful web services

Administrator

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" <[hidden email]>

>
> 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" <[hidden email]>
>> To: [hidden email]
>> 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
>>
>

Vince Clark

Re: restful web services

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.

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.

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.

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."

----- Original Message -----
From: "Jacques Le Roux" <[hidden email]>
To: [hidden email]
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" <[hidden email]>

Jacques Le Roux

Re: restful web services

Administrator

From: "Vince M. Clark" <[hidden email]>
> 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" <[hidden email]>
> To: [hidden email]
> 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" <[hidden email]>
>>
>> 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" <[hidden email]>
>>> To: [hidden email]
>>> 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
>>>
>>
>
>
>

Vince Clark

Re: restful web services

I'm getting close to clarity. Thanks for all the input so far.

Here are the three options I think we are discussing:
1) Use OFBiz service engine as is
2) Use Axis
3) Use ServiceMix

To be clear, I am referring to these options only for the purpose of communicating with OFBiz. There will be a separate ESB for enterprise services. Here is the fundamental premise behind this, please challenge it if I am wrong.

We need to connect to OFBiz via WS, then call OFBiz services for things like shopping cart, checkout, CRUD operations, etc. So I am looking at this from the perspective that I need a WS technology running "in container" rather than trying to consume EVERY OFBiz service as a web service.

----- Original Message -----
From: "Jacques Le Roux" <[hidden email]>
To: [hidden email]
Sent: Wednesday, March 11, 2009 8:38:10 AM (GMT-0600) America/Chicago
Subject: Re: restful web services

From: "Vince M. Clark" <[hidden email]>
> 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

Jacques Le Roux

Re: restful web services

Administrator

In reply to this post by Vince Clark

About JBI and OAGIS you might be interested byt this thread
http://mail-archives.apache.org/mod_mbox/servicemix-users/200809.mbox/%3Cb23ecedc0809020750p420f73c9saf260811ce472f53@...%3E

HTH

Jacques

From: "Jacques Le Roux" <[hidden email]>

> From: "Vince M. Clark" <[hidden email]>
>> 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" <[hidden email]>
>> To: [hidden email]
>> 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" <[hidden email]>
>>>
>>> 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" <[hidden email]>
>>>> To: [hidden email]
>>>> 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
>>>>
>>>
>>
>>
>>
>