Earlier today the OSGi 4.2 Enterprise spec was announced by David Bosschaert.
As part this announcement David listed some implementations of the OSGi 4.2 Remote Services specification, but for some strange reason he neglected to include the EclipseRT implementation from from ECF project.
So, just to be clear, EclipseRT/ECF 3.2 also already has support for OSGi 4.2 Remote Services. See here for details, links to docs, examples, and public support forums...as well as descriptions of other features in this implementation.
Tuesday, March 23, 2010
OSGi/EclipseRT in Amazon Cloud - p2
In a previous post, I announced the availability of a public Amazon Image (AMI) for the Amazon EC2 service that includes several EclipseRT 3.6 technologies...including Jetty 7.0.1 and Equinox 3.6M5.
p2 is also included in the image, and this allows install/update in a running OSGi web application server. Also included in the AMI is Jetty + Equinox 3.6M5 that does not include p2.
p2 is also included in the image, and this allows install/update in a running OSGi web application server. Also included in the AMI is Jetty + Equinox 3.6M5 that does not include p2.
Tuesday, March 16, 2010
OSGi/EclipseRT in Amazon Cloud
I've created a public Amazon Image (AMI) from a recent build (3.6 stream) of the EclipseRT. The parts of EclipseRT included in this image were Jetty, Equinox, p2 provisioning, and a very simple Hello World servlet application (with source).
Here is documentation about how to get the image, start an EC2 instance, and run your own server.
Here is an instance of this Hello World servlet application running on my instance.
Here is documentation about how to get the image, start an EC2 instance, and run your own server.
Here is an instance of this Hello World servlet application running on my instance.
Friday, February 19, 2010
ECF 3.2 Now Available
ECF 3.2 is now available here. The emphasis/theme for this release is support for Service-Oriented Architecture (SOA), specifically through support of the OSGi 4.2 Remote Services standard.
Highlights
Highlights
- Implementation of OSGi 4.2 Remote Services standard
- Support for REST providers
- Support for SOAP providers
- Remote Services Examples and Docs and recent blogging about the tech for this release
Tuesday, February 16, 2010
OSGi Remote Services and Sync vs. Async
ECF 3.2 contains an implementation of the new OSGi 4.2 remote services standard. This release is coming out later this week (Feb 19).
One thing that developers may discover when building and testing distributed applications is that synchronous remote procedure call (RPC) can have surprising behaviors. In my view, this is because we reflexively understand that normal/local/in memory method call is synchronous and fast...i.e. that the calling thread blocks until the method is complete (and optionally a result is returned), OR the method fails/throws an exception in languages that have structured exception handling.
So at best the remote call's I/O behavior will lead to large performance variability (i.e. the remote call will be orders of magnitude slower...and variable based upon network performance), and at worst the caller thread could hang/block indefinitely. This violates our expectations about method invocation.
To address this problem, frequently asynchronous remote method call and/or non-blocking messaging is used...so that the caller can be guaranteed that the calling thread will not block. Note that depending upon the application requirements and expectations, it may be fine that synchronous/blocking RPC is used. OTOH, it may be very important that remote services not block...for user experience, and or overall system performance expectations. It depends upon the use case...and I don't believe there is any one, 'right' answer for all situations.
ECF's implementation of the OSGi 4.2 remote services spec has support for asynchronous remote method call. This support is exposed via our IRemoteService contract, which is made available to remote service consumers (for example code, see tutorial here). This contract exposes two mechanisms for making asynchronous remote method calls
The IRemoteService reference associated with a remote service proxy is accessible via any/all ECF remote services. If not needed, however, it's invisible and so doesn't impose any complexity burden.
Currently, the OSGi 4.2 remote services spec does not articulate any methods for asynchronously accessing a remote service, but my understanding is that this is an area for future standardization.
One thing that developers may discover when building and testing distributed applications is that synchronous remote procedure call (RPC) can have surprising behaviors. In my view, this is because we reflexively understand that normal/local/in memory method call is synchronous and fast...i.e. that the calling thread blocks until the method is complete (and optionally a result is returned), OR the method fails/throws an exception in languages that have structured exception handling.
So at best the remote call's I/O behavior will lead to large performance variability (i.e. the remote call will be orders of magnitude slower...and variable based upon network performance), and at worst the caller thread could hang/block indefinitely. This violates our expectations about method invocation.
To address this problem, frequently asynchronous remote method call and/or non-blocking messaging is used...so that the caller can be guaranteed that the calling thread will not block. Note that depending upon the application requirements and expectations, it may be fine that synchronous/blocking RPC is used. OTOH, it may be very important that remote services not block...for user experience, and or overall system performance expectations. It depends upon the use case...and I don't believe there is any one, 'right' answer for all situations.
ECF's implementation of the OSGi 4.2 remote services spec has support for asynchronous remote method call. This support is exposed via our IRemoteService contract, which is made available to remote service consumers (for example code, see tutorial here). This contract exposes two mechanisms for making asynchronous remote method calls
- Asynchronous callback via IRemoteService.callAsync/2
- Futures via IRemoteService.callAsync/1
The IRemoteService reference associated with a remote service proxy is accessible via any/all ECF remote services. If not needed, however, it's invisible and so doesn't impose any complexity burden.
Currently, the OSGi 4.2 remote services spec does not articulate any methods for asynchronously accessing a remote service, but my understanding is that this is an area for future standardization.
Thursday, February 04, 2010
Goodness through OSGi Standards
ECF recently announced full support for OSGi 4.2's remote services standard with our upcoming 3.2 release.
Today, I learned that a community member has successfully used Spring dm, along with ECF's remote services implementation to do declaratively-specified remote services. They have agreed to contribute the example to ECF, and so expect to see it as part of ECF soon.
People have also used ECF remote services with OSGi declarative services.
And, of course, one can use remote services programmatically as well.
Among other things, this allows a wide variety of existing tooling to be used to construct, use, and debug remote services...all made possible by having an open standard for distributing an OSGi service.
Today, I learned that a community member has successfully used Spring dm, along with ECF's remote services implementation to do declaratively-specified remote services. They have agreed to contribute the example to ECF, and so expect to see it as part of ECF soon.
People have also used ECF remote services with OSGi declarative services.
And, of course, one can use remote services programmatically as well.
Among other things, this allows a wide variety of existing tooling to be used to construct, use, and debug remote services...all made possible by having an open standard for distributing an OSGi service.
Tuesday, January 12, 2010
Motivation 3.0
A question that I ask myself periodically is this: Why work on open source projects? In my case, why work on ECF? What is my motivation to do so?
There's an interesting book by Daniel Pink that examines human motivation called Drive: The Surprising Truth About What Motivates Us. There's also a nice YouTube video by the author from last year's TED conference.
In reading the first part of the book, I've resonated with his assertion that intrinsic motivation is sometimes stronger than extrinsic motivation...particularly when creativity (aka innovation) is involved. And I suspect I am not alone in this...at least among people who are passionate about innovation, community, software technology, and open systems.
I believe understanding motivations is important...because lots of assumptions about how innovation comes about...i.e. who does it and why...are actually dependent upon underlying assumptions about motivation.
There's an interesting book by Daniel Pink that examines human motivation called Drive: The Surprising Truth About What Motivates Us. There's also a nice YouTube video by the author from last year's TED conference.
In reading the first part of the book, I've resonated with his assertion that intrinsic motivation is sometimes stronger than extrinsic motivation...particularly when creativity (aka innovation) is involved. And I suspect I am not alone in this...at least among people who are passionate about innovation, community, software technology, and open systems.
I believe understanding motivations is important...because lots of assumptions about how innovation comes about...i.e. who does it and why...are actually dependent upon underlying assumptions about motivation.
Sunday, January 10, 2010
SOAP, REST, and ECF remote services
In addition to supporting the OSGi 4.2 remote services specification, we on the ECF team have also been working on support for accessing REST-style services, as well as those that use the Simple Object Access Protocol (SOAP).
The ability to support all these styles of service-oriented architecture is fundamentally enabled by ECF's provider architecture, but since mentioned that in a recent posting, in this post I'm going to touch on something useful that's enabled by this provider architecture.
Most remote services (whether web services, OSGi remote services, REST-based services, etc) have two basic roles
Typically, the service host is first 'registered'...to make it available for remote access, and after that the service consumer then accesses/uses the remote service (e.g. makes remote method calls on a proxy, issues http requests for resources, sends/receives messages, or has some other way of actually accessing/calling the remote service).
Note that the service host need not be exposed by a 'server' (although it frequently is)...in some systems clients can register/expose services as well as servers. And it's probably obvious that service consumers don't have to be 'clients' either...i.e. they can be servers that are communicating with other servers. This is why I use the role names 'host' and 'consumer' rather than 'server' and 'client' when referring to remote services.
OSGi remote services use the OSGi service registry...for both the host's registration of services, and the consumer's lookup and access to a remote service. Whatever the transport used to implement the distribution, typically both the host's registration and the consumer's lookup are done via the OSGi service registry. This typical use case implies, however, that both the host framework and the consumer framework have access to the OSGi service registry (since both registration and lookup are via the service registry).
But what if you would like to consume a service that doesn't use OSGi (and therefore doesn't have a service registry)? With ECF's remote services API, along with our recently added REST and SOAP support, we've enabled this use case (non-OSGi service host) while still providing the benefits of using OSGi remote services for the consumer.
How, you say? First of all, ECF's transport independent architecture allows clients to talk whatever protocol they require to communicate with a remote process...so, for example, the XMPP provider is able to communicate with any remote system that uses the (standardized) XMPP protocol. This does *not* have to be an OSGi-based system.
Second, ECF now has a very small, remote service client API...specifically to allow consumers to interact with non-OSGi services, while still using the OSGi service registry (if they wish) on the client. Since both the ECF remote services API, as well as this new remote service client API are also transport independent, and have both explicit support for REST-style and SOAP-based transports, providers for specific REST-based protocols and/or SOAP-based protocols are easy to create.
As an example, I recently created a SOAP/Web services client (for an existing web service), using Apache Axis (to convert wsdl to java), the WTP tooling (for automating the generation of the java code from wsdl), and this new remote services client API. To the non-OSGi service host, this client looks/behaves like all other clients. The same idea...for an existing REST-based API (Twitter in this case), is shown by this demo.
Unlike other clients, however, these clients can use OSGi to maximum value: i.e. to structure the client in a modular way, to handle the dynamic requirements of a remote/networked/unreliable service, or even (re) expose the proxy as a another remote service...that other consumers can access. This can be used for building load balancing of web services, or to aggregate sets of services...as well as other purposes.
Note there is no additional tooling required to build such a client...since your favorite tools for creating the SOAP-based and/or REST-based clients may be used, alongside APIs and tooling for interacting with the OSGi service registry...e.g. Eclipse PDE, OSGi declarative services and/or others.
The ability to support all these styles of service-oriented architecture is fundamentally enabled by ECF's provider architecture, but since mentioned that in a recent posting, in this post I'm going to touch on something useful that's enabled by this provider architecture.
Most remote services (whether web services, OSGi remote services, REST-based services, etc) have two basic roles
- The service host...aka the 'server'
- The service consumer...aka the 'client'
Typically, the service host is first 'registered'...to make it available for remote access, and after that the service consumer then accesses/uses the remote service (e.g. makes remote method calls on a proxy, issues http requests for resources, sends/receives messages, or has some other way of actually accessing/calling the remote service).
Note that the service host need not be exposed by a 'server' (although it frequently is)...in some systems clients can register/expose services as well as servers. And it's probably obvious that service consumers don't have to be 'clients' either...i.e. they can be servers that are communicating with other servers. This is why I use the role names 'host' and 'consumer' rather than 'server' and 'client' when referring to remote services.
OSGi remote services use the OSGi service registry...for both the host's registration of services, and the consumer's lookup and access to a remote service. Whatever the transport used to implement the distribution, typically both the host's registration and the consumer's lookup are done via the OSGi service registry. This typical use case implies, however, that both the host framework and the consumer framework have access to the OSGi service registry (since both registration and lookup are via the service registry).
But what if you would like to consume a service that doesn't use OSGi (and therefore doesn't have a service registry)? With ECF's remote services API, along with our recently added REST and SOAP support, we've enabled this use case (non-OSGi service host) while still providing the benefits of using OSGi remote services for the consumer.
How, you say? First of all, ECF's transport independent architecture allows clients to talk whatever protocol they require to communicate with a remote process...so, for example, the XMPP provider is able to communicate with any remote system that uses the (standardized) XMPP protocol. This does *not* have to be an OSGi-based system.
Second, ECF now has a very small, remote service client API...specifically to allow consumers to interact with non-OSGi services, while still using the OSGi service registry (if they wish) on the client. Since both the ECF remote services API, as well as this new remote service client API are also transport independent, and have both explicit support for REST-style and SOAP-based transports, providers for specific REST-based protocols and/or SOAP-based protocols are easy to create.
As an example, I recently created a SOAP/Web services client (for an existing web service), using Apache Axis (to convert wsdl to java), the WTP tooling (for automating the generation of the java code from wsdl), and this new remote services client API. To the non-OSGi service host, this client looks/behaves like all other clients. The same idea...for an existing REST-based API (Twitter in this case), is shown by this demo.
Unlike other clients, however, these clients can use OSGi to maximum value: i.e. to structure the client in a modular way, to handle the dynamic requirements of a remote/networked/unreliable service, or even (re) expose the proxy as a another remote service...that other consumers can access. This can be used for building load balancing of web services, or to aggregate sets of services...as well as other purposes.
Note there is no additional tooling required to build such a client...since your favorite tools for creating the SOAP-based and/or REST-based clients may be used, alongside APIs and tooling for interacting with the OSGi service registry...e.g. Eclipse PDE, OSGi declarative services and/or others.
Sunday, January 03, 2010
OSGi Remote Services from ECF
The ECF project has just finished our initial implementation of the OSGi 4.2 Remote Service specification (chapter 13 in compendium section).
I want to highlight a few distinctive features of ECF's implementation. I'll be doing other/more blog posts to go into details about some of these.
Transport Independence
ECF's implementation currently works with the following distribution transports: JMS (ActiveMQ), r-OSGi, JavaGroups, XMPP, Skype, ECF generic, and with the following discovery protocols: SLP, zeroconf, static xml file-based discovery. The ECF implementation is immediately usable with any...or all...of these providers...even within a single application if desired. Further, ECF's remote services and discovery APIs allow other distribution and/or discovery systems to be plugged in underneath our implementation...meaning that other distribution systems (e.g. open source distribution systems such as Riena, Apache CXF, and/or proprietary distribution systems) can reuse/leverage our implementation...and avoid the work otherwise necessary to implement the OSGi specification themselves. ECF's implementation can also run alongside other remote services implementations without conflict.
Asynchronous and Synchronous
Distributed applications and services frequently need to use asynchronous/non-blocking remote invocation patterns...in addition to synchronous, proxy-based remote method call. Right now, ECF has built-in support for both asynchronous invocation (e.g. asynchronous listeners, futures, one-ways), as well as proxy/synchronous invocation...giving the services and application programmer a transport-independent choice of which to use. Currently, the OSGi 4.2 spec does not yet specify asynchronous invocation patterns for remote services, but ECF's implementation does have it.
Lightweight
The entire ECF implementation of the spec...along with ECF's remote services API...is < 150k of code. Further, the OSGi execution environment requirements are minimal (CDC 1.1/Foundation 1.1). Combined with a small provider (like r-OSGi), and this allows even small devices to both expose/host and consume standardized remote services.
Standard, Open Source, Open Team, Open Process
The ECF implementation is fully compliant with the OSGi 4.2 remote services specification...for any and all current and future ECF remote services providers. Further, as mentioned above, other providers can now get this compliance for free. Of course, ECF's implementation is open source, but it is also produced by a vendor-neutral project team, and fully open community-driven process. In addition, we have support for a distributed version of the OSGi EventAdmin service, for doing publish-and-subscribe-based applications using a standard event bus API/service.
Extensible
ECF's implementation is deeply extensible, allowing control or customization of every aspect of the distribution of an OSGi service (e.g. custom discovery, custom marshalling/serialization, custom transport/wire protocol, etc) for those that need it. This is enabled by the open APIs that ECF exposes, and allows a wide variety of deployment requirements and application-level use cases to be easily supported.
Summary
It's All About Modules. ECF's modular structure is indeed enabled by OSGi's modularity, but we have also applied modular design to every level of APIs and implementations. For example, lightweightness, extensibility, and transport independence all are enabled by our modular designs...to separate API from implementation, and to separate distinct subsystems (e.g. discovery and remote services APIs).
We are preparing a release that includes this code...so to immediately download/use ECF's implementation, or engage the community...for requesting enhancements, reporting bugs, contributing (e.g. examples, providers, customizations), helping with testing, or getting support please consider joining the ecf dev mailing list or see the ecf dev resources page.
I want to highlight a few distinctive features of ECF's implementation. I'll be doing other/more blog posts to go into details about some of these.
Transport Independence
ECF's implementation currently works with the following distribution transports: JMS (ActiveMQ), r-OSGi, JavaGroups, XMPP, Skype, ECF generic, and with the following discovery protocols: SLP, zeroconf, static xml file-based discovery. The ECF implementation is immediately usable with any...or all...of these providers...even within a single application if desired. Further, ECF's remote services and discovery APIs allow other distribution and/or discovery systems to be plugged in underneath our implementation...meaning that other distribution systems (e.g. open source distribution systems such as Riena, Apache CXF, and/or proprietary distribution systems) can reuse/leverage our implementation...and avoid the work otherwise necessary to implement the OSGi specification themselves. ECF's implementation can also run alongside other remote services implementations without conflict.
Asynchronous and Synchronous
Distributed applications and services frequently need to use asynchronous/non-blocking remote invocation patterns...in addition to synchronous, proxy-based remote method call. Right now, ECF has built-in support for both asynchronous invocation (e.g. asynchronous listeners, futures, one-ways), as well as proxy/synchronous invocation...giving the services and application programmer a transport-independent choice of which to use. Currently, the OSGi 4.2 spec does not yet specify asynchronous invocation patterns for remote services, but ECF's implementation does have it.
Lightweight
The entire ECF implementation of the spec...along with ECF's remote services API...is < 150k of code. Further, the OSGi execution environment requirements are minimal (CDC 1.1/Foundation 1.1). Combined with a small provider (like r-OSGi), and this allows even small devices to both expose/host and consume standardized remote services.
Standard, Open Source, Open Team, Open Process
The ECF implementation is fully compliant with the OSGi 4.2 remote services specification...for any and all current and future ECF remote services providers. Further, as mentioned above, other providers can now get this compliance for free. Of course, ECF's implementation is open source, but it is also produced by a vendor-neutral project team, and fully open community-driven process. In addition, we have support for a distributed version of the OSGi EventAdmin service, for doing publish-and-subscribe-based applications using a standard event bus API/service.
Extensible
ECF's implementation is deeply extensible, allowing control or customization of every aspect of the distribution of an OSGi service (e.g. custom discovery, custom marshalling/serialization, custom transport/wire protocol, etc) for those that need it. This is enabled by the open APIs that ECF exposes, and allows a wide variety of deployment requirements and application-level use cases to be easily supported.
Summary
It's All About Modules. ECF's modular structure is indeed enabled by OSGi's modularity, but we have also applied modular design to every level of APIs and implementations. For example, lightweightness, extensibility, and transport independence all are enabled by our modular designs...to separate API from implementation, and to separate distinct subsystems (e.g. discovery and remote services APIs).
We are preparing a release that includes this code...so to immediately download/use ECF's implementation, or engage the community...for requesting enhancements, reporting bugs, contributing (e.g. examples, providers, customizations), helping with testing, or getting support please consider joining the ecf dev mailing list or see the ecf dev resources page.
Friday, December 18, 2009
Some new browser-based smartphone tooling
Project Ares is a new browser-based development tool for Palm/WebOS
Wednesday, December 09, 2009
Cloud + OSGi + GWT + ECF Rest + Twitter API = Modular web services
Using several technologies, I've recently created a Twitter user status service...i.e. a web service that retrieves the latest user status for a given user.
Click here to use/try it
You will need a Twitter username and password to get that user's status.
Here's what was used
Web Server: EclipseRT, p2, Equinox servletbridge
Ajax Web UI: Google Web Toolkit (GWT)
REST API: ECF REST/remote services API, Twitter REST API/service
Cloud provider: Amazon Cloud/Web Services (AWS)
The use of OSGi modularity makes this not only possible, but lightweight...as this server/service consists only of the bundles necessary to actually provide this service...and each of those used are small.
Click here to use/try it
You will need a Twitter username and password to get that user's status.
Here's what was used
Web Server: EclipseRT, p2, Equinox servletbridge
Ajax Web UI: Google Web Toolkit (GWT)
REST API: ECF REST/remote services API, Twitter REST API/service
Cloud provider: Amazon Cloud/Web Services (AWS)
The use of OSGi modularity makes this not only possible, but lightweight...as this server/service consists only of the bundles necessary to actually provide this service...and each of those used are small.
Tuesday, December 01, 2009
why we cooperate
It's a little hard for me to believe these days, but cooperation seems to be built in http://www.nytimes.com/2009/12/01/science/01human.html
Perhaps it's time to behave more like children.
Perhaps it's time to behave more like children.
Thursday, November 19, 2009
ECF provides some additional REST
ECF was very fortunate to have 4 Google Summer of Code projects coming out of the summer of 2009. All of these innovative codebases will make it into ECF itself...and more importantly we have gained several excellent new committers.
Coming out of the GSOC project, we've just finished a major refactoring of the REST API, to make it simpler, smaller, as well as better integrated with ECF remote services.
The integration with ECF remote services is particularly interesting, because it provides both proxy-based/synchronous invocation, as well as full support for asynchronous invocation patterns (i.e. asynchronous-with-listener-callback and futures). With the integration with ECF remote services, the choice of synchronous/asynchronous invocation comes for free for all REST-based remote services. See here to get the REST projects and use the API.
We are working on example code, and invite contributions from community members to this effort...so that we can continuously improve/simplify the API through community feedback, as well as get a wide range of example code and documentation from existing and new REST-based services. See the ecf-dev mailing list for feedback/discussion/coordination.
The current test code uses the popular Twitter REST API...as an example of using the API to interoperate with non-OSGi, non-Eclipse, perhaps non-Java web service (I don't know/care how the Twitter service is actually implemented...which is what protocol-level interoperability is about).
Coming out of the GSOC project, we've just finished a major refactoring of the REST API, to make it simpler, smaller, as well as better integrated with ECF remote services.
The integration with ECF remote services is particularly interesting, because it provides both proxy-based/synchronous invocation, as well as full support for asynchronous invocation patterns (i.e. asynchronous-with-listener-callback and futures). With the integration with ECF remote services, the choice of synchronous/asynchronous invocation comes for free for all REST-based remote services. See here to get the REST projects and use the API.
We are working on example code, and invite contributions from community members to this effort...so that we can continuously improve/simplify the API through community feedback, as well as get a wide range of example code and documentation from existing and new REST-based services. See the ecf-dev mailing list for feedback/discussion/coordination.
The current test code uses the popular Twitter REST API...as an example of using the API to interoperate with non-OSGi, non-Eclipse, perhaps non-Java web service (I don't know/care how the Twitter service is actually implemented...which is what protocol-level interoperability is about).
Monday, October 19, 2009
Load balancing remote services
Hi Folks,
The ECF wiki now has example code for doing dynamic load balancing of remote services.
This implementation uses a JMS Queue (via ActiveMQ implementation of JMS) to do the dynamic load balancing of ECF remote service requests/method invocations.
The thing that I like most about this is that it's extremely simple, small...and doesn't require any special/custom code to use. Clients/consumers just lookup/use a remote service, and upon usage the service implementation load balances the requests among an arbitrary set of target servers.
The ECF wiki now has example code for doing dynamic load balancing of remote services.
This implementation uses a JMS Queue (via ActiveMQ implementation of JMS) to do the dynamic load balancing of ECF remote service requests/method invocations.
The thing that I like most about this is that it's extremely simple, small...and doesn't require any special/custom code to use. Clients/consumers just lookup/use a remote service, and upon usage the service implementation load balances the requests among an arbitrary set of target servers.
Monday, October 12, 2009
ECF 3.1 released
ECF 3.1 is now released. See here for download, and here for New and Noteworthy. Lots of very cool stuff being contributed (and that's without mentioning the upcoming Google Wave provider :).
Congrats to the ECF contributors, committers, and community.
Congrats to the ECF contributors, committers, and community.
Saturday, October 10, 2009
ECF 3.1
ECF 3.1 is being released on Monday next (10/12/2009), and there are some exciting additions:
- REST API - An extension of the ECF remote services API to allow interoperation between OSGi remote services and REST-based services
- Distributed EventAdmin - a Distributed implementation of the OSGi EventAdmin service, that uses JMS/ActiveMQ for transport (and/or other providers)
- Lots of small improvements on ECF remote services, as well as examples and additional documentation
- File-based Discovery - a contribution from Siemens for doing remote service discovery using a static endpoint-URI exposed via an xml format
Sunday, November 02, 2008
Innovation
There's an article about technology innovation in bad economic conditions in today's NY Times:
It's No Time to Forget About Innovation
I believe this is something to remember...particularly for Eclipse committers...since in my view they are the innovators in the Eclipse community.
It's No Time to Forget About Innovation
I believe this is something to remember...particularly for Eclipse committers...since in my view they are the innovators in the Eclipse community.
Tuesday, October 14, 2008
ECF and Coffee in the Classroom
There was a very cool announcement on the ECF newsgroup recently about a collaboration framework that uses ECF called Coffee. See here for the announcement. The Coffee end user site is here, and the development site is here. It's exciting for me to see ECF being used by projects both inside and outside the Eclipse Foundation...and as as you can see from the announcement they are keen to both collaborate and contribute back to the open source community.
Enjoy the beverage!
Enjoy the beverage!
Friday, October 03, 2008
Planning for ECF 3.0
ECF is nearly finished moving from Technology to the new Runtime project, and we are doing planning for ECF 3.0/Galileo. See the new plan here.
Please make enhancement requests and/or start discussion about desired features in the dev mailing list...and let us know what features, changes, or bug fixes you want for ECF 3.0.
Please make enhancement requests and/or start discussion about desired features in the dev mailing list...and let us know what features, changes, or bug fixes you want for ECF 3.0.
Thursday, August 07, 2008
Some Disturbing Things from Microsoft
Open Source: A 'Growing Challenge' to Microsoft
There's an MS quote that is particularly disturbing to me
"The availability of protocol licenses may enable competitors to develop software products that better mimic the functionality of Microsoft's own products which could result in a reduction in sales of our products."
This is disturbing because it's pits protocol/service interoperability (a user need) against MS's sales (a MS shareholder need). Let's hope this doesn't result in MS pulling back from protocol openness.
There's an MS quote that is particularly disturbing to me
"The availability of protocol licenses may enable competitors to develop software products that better mimic the functionality of Microsoft's own products which could result in a reduction in sales of our products."
This is disturbing because it's pits protocol/service interoperability (a user need) against MS's sales (a MS shareholder need). Let's hope this doesn't result in MS pulling back from protocol openness.
Subscribe to:
Posts (Atom)