REST Web Services integration

Hello,

We have been using cocoon pipelines for about the last two years
as a vehicle to develop RESTfull web services. We have a legacy HTML web
application which we are planning to redevelop over the next four years or so.
I have been investigating OPS for just the last two weeks or so primarily as
tool to redevelop our Web front end application. So far OPS looks rather good.
We will need OPS to communicate with our cocoon pipelines. I have successfully done this using the OPS delegation processor, but I needed to put all the usual SOAP headers/envelope etc. which to me are useless. This also requires changes to the Cocoon pipelines. Is there a way to avoid this and just send XML over HTTP to
my cocoon end point?

Regards,
Franco



--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

i Franco,

[hidden email] wrote:
 > Hello,
 >
 > We have been using cocoon pipelines for about the last two years as
 > a vehicle to develop RESTfull web services. We have a legacy HTML
 > web application which we are planning to redevelop over the next
 > four years or so.

 > I have been investigating OPS for just the last two weeks or so
 > primarily as tool to redevelop our Web front end application. So far
 > OPS looks rather good.

Thanks :-)

 > We will need OPS to communicate with our cocoon pipelines. I have
 > successfully done this using the OPS delegation processor, but I
 > needed to put all the usual SOAP headers/envelope etc. which to me
 > are useless. This also requires changes to the Cocoon pipelines. Is
 > there a way to avoid this and just send XML over HTTP to my cocoon
 > end point?

Great question. In fact this is almost a FAQ. We have been planning
forever to either include a POST/HTTP Client processor, or to update
the existing URL generator to support POST.

As a BTW, the XForms engine already supports posting XML, and there
was also a code contribution made a while ago which has not yet been
integrated, the priority remaining finishing up the XForms engine.

The feature is even planned for 3.0, but we don't know if we will
actually have the time to complete that:

   https://wiki.objectweb.org/ops/Wiki.jsp?page=DynamicXFormsFinal

The bottom line is that this feature is a recognized need, but so far
it has not made it into the code base. Note that as usual it is
possible to accelerate this kind of things through sponsoring :-)

-Erik



--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

Thanks for the update Erik,
At least it's on your radar as something useful. We are still evaluating and
this is not stopping the evaluation. I will keep the option of 'sponsoring'
the feature in my mind if the evaluation is successfull.

BTW another issue that i will need to try out concerns the DB processor. But you
may be able to fast-track an answer that will save me some work. Is the DB processor
transactional? That is can I call it a number of times and then decide whether to
commit/rollback the set?

Regards,
Franco

-----Original Message-----
From: Erik Bruchez [mailto:[hidden email]]
Sent: Thursday, 18 August 2005 4:29
To: [hidden email]
Subject: Re: [ops-users] REST Web Services integration


i Franco,

[hidden email] wrote:
 > Hello,
 >
 > We have been using cocoon pipelines for about the last two years as
 > a vehicle to develop RESTfull web services. We have a legacy HTML
 > web application which we are planning to redevelop over the next
 > four years or so.

 > I have been investigating OPS for just the last two weeks or so
 > primarily as tool to redevelop our Web front end application. So far
 > OPS looks rather good.

Thanks :-)

 > We will need OPS to communicate with our cocoon pipelines. I have
 > successfully done this using the OPS delegation processor, but I
 > needed to put all the usual SOAP headers/envelope etc. which to me
 > are useless. This also requires changes to the Cocoon pipelines. Is
 > there a way to avoid this and just send XML over HTTP to my cocoon
 > end point?

Great question. In fact this is almost a FAQ. We have been planning
forever to either include a POST/HTTP Client processor, or to update
the existing URL generator to support POST.

As a BTW, the XForms engine already supports posting XML, and there
was also a code contribution made a while ago which has not yet been
integrated, the priority remaining finishing up the XForms engine.

The feature is even planned for 3.0, but we don't know if we will
actually have the time to complete that:

   https://wiki.objectweb.org/ops/Wiki.jsp?page=DynamicXFormsFinal

The bottom line is that this feature is a recognized need, but so far
it has not made it into the code base. Note that as usual it is
possible to accelerate this kind of things through sponsoring :-)

-Erik




--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

Franco,

I assume you are talking about the SQL processor? It is transactional
in this way: OPS sets autocommit to false and commits SQL connections
upon successful completion of a request (usually an HTTP request), or
roll them back upon error. So by default, you get one transaction by
request.

You can call the SQL processor any number of times you want. You can
commit or rollback explicitly on the way by explicitly sending a
"commit" or "rollback" SQL command.

If you have multiple databases, transactional integrity is not 100%
ensured. OPS will commit or rollback all connections to all databases,
but if something bad happens between two commits and rollbacks, you
are in trouble. This could be improved by using the appropriate APIs.

-Erik

[hidden email] wrote:
 > Thanks for the update Erik,
 > At least it's on your radar as something useful. We are still
evaluating and
 > this is not stopping the evaluation. I will keep the option of
'sponsoring'
 > the feature in my mind if the evaluation is successfull.
 >
 > BTW another issue that i will need to try out concerns the DB
processor. But you
 > may be able to fast-track an answer that will save me some work. Is
the DB processor
 > transactional? That is can I call it a number of times and then
decide whether to
 > commit/rollback the set?
 >
 > Regards,
 > Franco




--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

Hi Erik,
Yes, I do mean the SQL processor. That startegy sounds fine.
It means that once an SQL processor is called/invoked, then
it must keep the pooled connection to the DB until the entire
request completes. So if I call the processor n times within
a single HTTP request, then OPS keeps a hold of upto n pooled
connections and performs a commit/rollback on each of the
connections at the end of the request. Is that right?

Franco

-----Original Message-----
From: Erik Bruchez [mailto:[hidden email]]
Sent: Friday, 19 August 2005 10:55
To: [hidden email]
Subject: Re: [ops-users] REST Web Services integration


Franco,

I assume you are talking about the SQL processor? It is transactional
in this way: OPS sets autocommit to false and commits SQL connections
upon successful completion of a request (usually an HTTP request), or
roll them back upon error. So by default, you get one transaction by
request.

You can call the SQL processor any number of times you want. You can
commit or rollback explicitly on the way by explicitly sending a
"commit" or "rollback" SQL command.

If you have multiple databases, transactional integrity is not 100%
ensured. OPS will commit or rollback all connections to all databases,
but if something bad happens between two commits and rollbacks, you
are in trouble. This could be improved by using the appropriate APIs.

-Erik

[hidden email] wrote:
 > Thanks for the update Erik,
 > At least it's on your radar as something useful. We are still
evaluating and
 > this is not stopping the evaluation. I will keep the option of
'sponsoring'
 > the feature in my mind if the evaluation is successfull.
 >
 > BTW another issue that i will need to try out concerns the DB
processor. But you
 > may be able to fast-track an answer that will save me some work. Is
the DB processor
 > transactional? That is can I call it a number of times and then
decide whether to
 > commit/rollback the set?
 >
 > Regards,
 > Franco





--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

--- [hidden email] wrote:

> Hi Erik,
> Yes, I do mean the SQL processor. That startegy sounds fine.
> It means that once an SQL processor is called/invoked, then
> it must keep the pooled connection to the DB until the entire
> request completes. So if I call the processor n times within
> a single HTTP request, then OPS keeps a hold of upto n pooled
> connections and performs a commit/rollback on each of the
> connections at the end of the request. Is that right?

Hi Franko,

That's almost it. If during a request you call the SQL processor multiple
times for the same data source, then the same connection will be used. And
like you say, that connection will be kept until the end of the request
(to either commit or roll back the operations that have been performed so
far).

Alex

--
Blog (XML, Web apps, Open Source): http://www.orbeon.com/blog/



--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

Thanks Alex,
I couldn't think of a better policy. Much better than Cocoon!
So far you OPS has my vote.

Franco

-----Original Message-----
From: Alessandro Vernet [mailto:[hidden email]]
Sent: Saturday, 20 August 2005 2:51
To: [hidden email]
Subject: RE: [ops-users] REST Web Services integration


--- [hidden email] wrote:

> Hi Erik,
> Yes, I do mean the SQL processor. That startegy sounds fine.
> It means that once an SQL processor is called/invoked, then
> it must keep the pooled connection to the DB until the entire
> request completes. So if I call the processor n times within
> a single HTTP request, then OPS keeps a hold of upto n pooled
> connections and performs a commit/rollback on each of the
> connections at the end of the request. Is that right?

Hi Franko,

That's almost it. If during a request you call the SQL processor multiple
times for the same data source, then the same connection will be used. And
like you say, that connection will be kept until the end of the request
(to either commit or roll back the operations that have been performed so
far).

Alex

--
Blog (XML, Web apps, Open Source): http://www.orbeon.com/blog/




--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws