[
https://issues.apache.org/jira/browse/OODT-139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12995872#comment-12995872
]
Paul Ramirez edited comment on OODT-139 at 2/17/11 4:14 PM:
------------------------------------------------------------
Agree with Chris on the terminology to use should be at the cas-workflow level
and the root URL for the service should have "/wfmgr" and not "/wengine". While
this may seem merely cosmetic it will help keep thing straight when looking at
documentation and architecture diagrams.
@Brian Let's move this documentation to the Wiki page. If that is an endpoint
for viewing a workflow instance there is no need for the outer "workflow:" and
instead should just start with the { "completiondate": ....}. The consumer of
this endpoint should know that they will be getting a workflow instance as that
is the way the documentation will read. Also, what does the endpoint look like?
My guess is something along the lines of /workflows/{instanceid}. In general it
may make sense to return a more minimal representation of the workflow instance
instead of all the level of detail you have above. For instance, maybe do
something like "posconditions":["TestPostCondModelName"]. Then you could have
an endpoint to get the set of postconditions (i.e.
/workflows/{instanceid}/postconditions) and maybe even an endpoint for
addressing a single condition (i.e.
/workflows/{instanceid}/postconditions/{modelname}). The same could be said for
preconditions and subprocessors as its not very likely that you are going to
need all this information unless you have a specific use case in mind. Thanks
for pushing this stuff out there it really helps to see where its going on
early on.
was (Author: pramirez):
Let's move this documentation to the Wiki page. If that is an endpoint for
viewing a workflow instance there is no need for the outer "workflow:" and
instead should just start with the { "completiondate": ....}. The consumer of
this endpoint should know that they will be getting a workflow instance as that
is the way the documentation will read. Also, what does the endpoint look like?
My guess is something along the lines of /workflows/{instanceid}. In general it
may make sense to return a more minimal representation of the workflow instance
instead of all the level of detail you have above. For instance, maybe do
something like "posconditions":["TestPostCondModelName"]. Then you could have
an endpoint to get the set of postconditions (i.e.
/workflows/{instanceid}/postconditions) and maybe even an endpoint for
addressing a single condition (i.e.
/workflows/{instanceid}/postconditions/{modelname}). The same could be said for
preconditions and subprocessors as its not very likely that you are going to
need all this information unless you have a specific use case in mind.
> PCS JAX-RS services
> -------------------
>
> Key: OODT-139
> URL: https://issues.apache.org/jira/browse/OODT-139
> Project: OODT
> Issue Type: New Feature
> Components: pcs
> Reporter: Chris A. Mattmann
> Assignee: Chris A. Mattmann
> Labels: jaxrs, jsr311, pcs
> Fix For: 0.3
>
> Attachments: OODT-139.Hart.021611.patch.txt,
> OODT-139.Mattmann.021311.patch.txt, OODT-139.Mattmann.021411.2.patch.txt,
> OODT-139.Mattmann.021411.patch.txt
>
>
> Now that the PCS core is contributed, it would be great to not just have
> command line versions and APIs for tools like pcs_stat, pcstrace and pcs_ll.
> We should expose them over JAX-RS so that webapps can easily take advantage
> of PCS services.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
