ohf-dev-bounces@xxxxxxxxxxx wrote on 04/04/2006 04:48:26 PM:
Hi Eishay
a couple of questions.
They want to expose OSGi plugins as web services, but if
their timelines don't suit, then we will continue with
the current OSGi/Server implementation. I'm confused - are
they setting themselves up in competition with the current
work, or are they going to extend it? I don't really
understand that choice you propose that we make.
They will use OSGi/Server, but I understood that the first phase they will
do will be based on the Eclipse HTTPService contained in an RCP and not in
a web container. I don't see a direct competition between them and the
OSGi/Server. Corona offer a methodology of exposing extension points as web
services, OSGi/Server offer a methodology of using plugins in a server
environment. There can (and will) be a Corona on OSGi/Server and they will
happily live together.
The near term goal of the OHF Bridge will be to bridge between OHF plugins
and 3'rd party applications. I wish to hear feedback if anyone thinks the
goal should be modified.
To do that, it seems like web services is the right communication platform
since it is widely accepted as a way to communicate between applications.
The choice is whether to implement the SOAP layer ourselves or to use
Corona's infrastructure. If we would do it all ourselves (using
OSGi/Server) then we will use the Axis package and maintain the glue code
between the SOAP protocol and the call for our plugins. Going with Corona
will make us dependent on another project which is in similar stage as we
are, but will give us its technology dedicated team to work with and its
future enhancements: management, code maintain, adaptation to ESB
platforms, and tooling.
My feeling is that we should reuse code from other project as much as we
can, especially if it is in the other project core goals. But on the other
hand, we should make sure we will not delay our schedule.
The second question is more general. Web Services are supposed
to be fairly coarse interfaces, whereas plug-in's generally
are pretty fine. Also, there's things you can pass across a
plug-in boundary that don't map into a web services paradigm.
So presumably you'd design a plug-in rather differently to be
able to publish it as a web service. Does this have design
implications for us now?
We think the same here. I think we should not have a "one size fit all"
plugin since it will lead to the unwanted "Least Common Dominator". My
thoughts are that there will be a "simplification plugin" that will expose
interface more suitable to web services, and will probably not expose the
full power of using the plugin from within the RCP.
This reminds me of a discussion I had with some folks who were
going to write a webservice tool that helped you construct
HL7 messages - it turned out to be rather circular because
that's fundamentally a fine grained concept, whereas web
services means messages, and defining the messages you use
to build a message turned out to be a fruitless exercise.
Grahame
Eishay Smith wrote:
I've talked with the Corona team today.
http://www.eclipse.org/proposals/corona/
Their project is about exposing OSGi Plugins as web services, which is
what
we wish to do.
Since we wish to focus on healthcare and reuse as much 3'rd party code
as
we can, I think we should try to use their code.
They are very interested to work with us, but only in the next week
they
will have a good knowledge of their time tables.
We decided we'll talk next week and see if we can plan on
collaboration.
I told them about our plans to have SOAP interfaces to our plugins by
August, and start integration with EMR vendors by then.
If they will be able to commit to that, I assume we should work with
them.
If not, we better continue with the current OSGi on Server
implementation
and re-evaluate their work next year.
Other pros in working with them are that they will work closely with
the
STP (SOA Tools Project), they intend to make use of SCA components by
next
year, and we are not the only user they will have this year.
If anyone wants to join future calls with them, please let me know.
Eishay
_______________________________________________
ohf-dev mailing list
ohf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ohf-dev
--
Grahame Grieve
CTO, Jiva Medical Software Integration Tools
CTO, Kestral Computing Healthcare Applications
_______________________________________________
ohf-dev mailing list
ohf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ohf-dev
_______________________________________________
ohf-dev mailing list
ohf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ohf-dev