Ticket #319 (closed task: wontfix)
Opened 2011-01-14T16:06:13-06:00
Last modified 2014-05-01T07:10:33-05:00
Web Service / SOA Implementation
| Reported by: | rlentz | Owned by: | curtis |
|---|---|---|---|
| Priority: | minor | Milestone: | imagej-3.0.0 |
| Component: | Plugin Framework | Version: | |
| Severity: | minor | Keywords: | |
| Cc: | Blocked By: | ||
| Blocking: |
Description
Binary web services can allow rapid adoption of modular code as ImageJ plugins. Specifically, this approach targets rapid implementations of modular code components in languages other than Java.
This task consists of several steps: Add SOA discovery code to WFP, set up VM instances for Windows and Linux that serve functionality published to the service directory
Identify prior sobel filter code in python, c, and c++. Configure a publish mechanism that allows users to publish implementation services to a centralized SOA service directory. Demo publication to the directory, module discovery within WFP, incorporation into WFP, and use from IJ1 as a plugin.
Create tutorials in the WFP documentation for uses demonstrating how to add implementations in languages other than Java into the WFP plugin handling infrastructure (export as IJ1/IJ2 plugin).
Change History
comment:1 Changed 2011-02-23T10:38:59-06:00 by rlentz
- Milestone changed from biweekly-2011: Feb-14 to Feb-25 to imagej-2.0-release
comment:2 Changed 2011-03-13T21:32:32-05:00 by curtis
- Owner changed from rlentz to curtis
- Status changed from new to assigned
- Milestone imagej-2.0-final deleted
comment:3 Changed 2011-08-02T11:04:48-05:00 by curtis
- Milestone set to imagej-3.0
The focus of this ticket could be to enable the ImageJ module framework to call web-services-based code from non-Java languages. Integration with WFP would come for free by virtue of it integrating with the ImageJ module framework in general.
comment:4 Changed 2014-05-01T07:10:33-05:00 by curtis
- Status changed from assigned to closed
- Resolution set to wontfix
It would still be nice to have a web-services-based interoperability mechanism for ImageJ plugins. But until we have some concrete use cases let's hold off. This issue will likely come up again in the future, but is not urgent and does not require a ticket reminding us to someday do the work.