Foundation Announces Maintainers Fund

 Rust Foundation Announces Maintainers Fund

Building MCP Servers - part 3: Security

There have been recent reports of critical security vulnerabilities on the mcp-remote project, and the mcp inspector project.

I do not know all the technical details of the exploits, but it appears to me that in both cases it has to do vulnerabilities introduced by the MCP Server implementation. and use of the stdio MCP transport.

I want to emphasize that example described in these two posts

Integration via Remote Tools

Example Using Remote Services

is using mechanisms that are...though heavy usage by commercial server technologies over the past 10 years...not subject to the same sorts of remote vulnerabilities seen by the mcp-remote and mcp-inspector projects.   

Also, the flexibility in discovery and distribution provided by the RSA Specification and the RSA implementation used, allows for addressing MCP Server remote tools, or protocol weaknesses, quickly and easily, without having to update the MCP Server or tooling implementation code.  

 

 

 

Building MCP Servers: Integration via Remote Tools

It has become popular to build Model Context Protocol Servers.  This makes a lot of sense from the developer-as-integrator point of view, since the MCP specification and multi-language SDKs make it possible to easily integrate resources, prompts, and tools into multiple LLMs without having to use the model-and-language-specific model APIs directly.

MCP tools spec provides a general way for LLMs to use tool meta-data (e.g. text descriptions) for the tool's required input data, behavior, and output data.  These text descriptions can then be used by the LLM...in combination with interaction with the user...to decide when and how to use the tool...i.e. to call the function and provide some output to the LLM and/or the user.

Building an MCP Server

When creating a new MCP Server, it's easiest to create the tool metadata and implement the tool functionality as part of a new MCP server implementation.   But this approach requires that every new tool (or integration with existing API/servers) results in a new MCP server or an update/new version of an existing MCP server.

Remote Tools

It's frequently better architecture to decouple the meta-data declaration and implementation of a given tool from the MCP Server itself, and allow the MCP Server to dynamically add/remove tools at runtime, as tools can then be discovered, added, meta-data made available to the model(s), called, evaluated, and potentially removed or updated without the creation of an entirely new MCP Server, but rather dynamically discovering, securing, importing, using, evaluating, updating, and removing tools from an MCP Server.  

This approach is potentially more secure (as it allows tool-specific authentication and access control), more flexible, and more scalable, since remote tools can be distributed on multiple hosts over a network.  And it allows easy integration with existing APIs.

In the next post I describe a working example that uses remote tools.

ECF 3.14.19 released - simplify remote service discovery via properties

 ECF 3.14.19 has been released.

Along with the usual bug fixes, this release includes new documentation on the use of properties for discovering and importing remote services.   The docs describe the use of properties files for simplifying the import of remote services.   

This capability is especially useful for Eclipse RCP clients accessing Jax-RS/REST remote services.

Patrick Paulin describes a production usage his blog posting here.

OSGi Remote Services with Apache Dubbo

ECF's implementation of OSGi R7 Remote Services allows for replacing the underlying distribution system (repsonsible for the object serialization, transport, and other things). 

This makes it relatively easy to replace one kind of distribution (e.g. Jersey, ActiveMQ) with other/new distribution systems. 

Apache Dubbo has recently been contributed to Apache, and we've created a distribution provider based upon Apache Dubbo.

Here's a list of open ECF Remote Service distribution providers.   If you would like Remote Services support for a particular transport, or you've created your own distribution (or discovery) based upon some other transport and wish to make it available to others please let us know.

Remote Services without OSGi bundles

Remote Services provides a dynamic, transport-independent, simple, modular way to expose micro services.   ECF has created a spec-compliant implementation along with a large and growing number of open and extensible distribution providers.   

Remote services are frequently useful for fog/edge use cases, where the communication transports (e.g. MQTT) may be different than those typically used in the cloud (e.g. http/https, jaxrs, enterprise messaging, etc).   

Typically, remote services are run on OSGi-based frameworks and apps such as Equinox, Felix, Karaf, Eclipse, and others, and indeed ECF's RSA implementation works very well in any of these environments.   

Perhaps less well known, however, is that remote services can be used in other inter-process environments...for example between Java and Python.  

It's also possible to use ECF remote services without an OSGi framework, i.e. running only as Java applications.   This repository has an example of using ECF remote services without an OSGi framework.   The projects are Java applications (no OSGi framework assumed), on both the remote service provider side, as well as the remote service consumer side.   The examples may be run within Eclipse by using the launch configs in the example projects.

Most of the benefits of OSGi Remote Services are still available...for example the ability to use multiple distribution providers for a service, the ability to remotely discover services and dynamically respond to network failure, and the ability to use the OSGi service registry for service dynamics, and service injection.   Also, the service definition, implementation, registration and lookup are exactly the same whether via an OSGi bundle or a Java application.   This allows services to be defined consistently across runtime environments in addition to cross-distribution mechanisms.

Please clone the ServiceRegistry github repository and give things a try!

Remote Services between Python and Java

ECF's implementation of OSGi Remote Services allows multiple distribution providers, which are responsible for the actual rpc communication required by remote services.   Here is a list of ECF distribution providers we've created.

Using Py4j and Google Protocol Buffers, we've recently enhanced an ECF distribution provider that allows the use of remote services (and Remote Service Admin) between OSGi and Python.   Service impls can be in either Java or Python, and consumers can be either Java or Python.     Protocol Buffers can be used to efficiently serialize arguments and return values.

The only dependencies are on OSGi, Py4j, and Google Protocol buffers, so this distribution provider can be used in Eclipse or other OSGi environments like Karaf.

Get the most recent release, with examples and source code at this github repository.

ECF 3.13.8 and etcd discovery for remote services

ECF 3.13.8 has been available since September, but there are some new things available:

ECF 3.13.8 changes have distributed to maven central

There is a new release (1.3.0) of the etcd discovery provider.    This provider uses an ectd cluster to publish and discover remote services allow complete integration with systems like Kubernetes, which also use etcd for service discovery.

Network Dynamics and Micro Services

One of the most challenging aspects of building networked applications is dealing with network dynamics. Networks and endpoints go down, sometimes come back up, and this implies that consumers accessing these services have to respond as these changes occur.

This will be even more true for the Internet of Things (IoT), where a wide variety of devices and a wide variety of networks will be involved to support the use of a micro service. Through no design or programming fault, IoT services and the applications that depend upon them will be less reliable.

How should micro-service consumers respond to failure? That's a good question, as the answer clearly depends upon the application-level needs and requirements.

For example, once loaded an html web page does not need to know/respond to the failure of the web server or the dropping (or changing due to mobility) of the network connecting the browser to the web server. If the user clicks on a link to present another page the load of the page will fail, but for browsing web pages that's a completely acceptable strategy for handling network failure.

On the other hand, consider an IoT application where a real-time data stream is collected from a sensor device. In such a case it might make more sense to have strategy for responding to network and/or device failure such as switching to a backup, or perhaps presenting to a user or admin that the data stream is temporarily unavailable. The larger point is that consumers of a micro service will differ in their requirements for responding to network failures.

What does any of this have to do with micro services? Frequently it falls to the application to not only define a strategy for application-level failure handling, but also to implement the networking code to detect failure and to use this detection to allow an application to implement a failure-handling strategy. This networking code can be a very difficult thing to create, especially if it has to meet multiple service and application-level requirements.

There are now specifications allowing the excellent dynamics support in OSGi Services to be used for Remote Services. The OSGi Service Registry, was designed to support dynamic within-process services. This allows applications to respond to services that come and go dynamically without having to create all the software infrastructure to do so reliably. Further, there are now OSGi specifications for Remote Services, and these allow the same dynamics support to be used to respond to network dynamics. Since the OSGi service registry is standardized, applications can also use (rather than build) convenient frameworks like Declarative Services/SCR or Spring/Blueprint to respond to network-induced service changes.

In short, the OSGi service registry and Remote Services provide standardized support for micro services dynamics without being bound by implementation to a specific protocol/transport, or even language.

Remote Services over (Unreliable) Networks

In a previous post, I described how ECF Remote Services provided a way to create, implement, test, deploy and upgrade transport-independent remote services.

Note that 'transport-independent' does not mean 'transparent'.

For example, with network services it's always going to relatively likely that a remote service (whether an OSGi Remote Service or any other kind of service) could fail at runtime.   The truth of this is encapsulated in the first fallacy of distributed computing:  The network is reliable.

A 'transparent' remote services distribution system would attempt to hide this fact from the service designer and implementer.   Alternatively, the ECF Remote Services approach allows one to choose a distribution provider(s) to meet the reliability and availability requirements for that remote service, and/or potentially change that selection in the future if requirements change.  

Also, the dynamics of OSGi services (inherited by Remote Services), allows network failure to be mapped by the distribution system to dynamic service departure.   For example, using Declarative Services, responding at the application level to a network failure can be as simple as implementing a method:

void unbindStudentService(StudentService service) throws Exception {
        // Make service unavailable to application
	this.studentService = null;
        // Also could respond by using/binding to a backup service, removing
        // service from UI, etc
}

This is only possible if

1. The distribution system detects the failure
2. The distribution system maps the detected failure to a service unregistration of the proxy

If those two things happen, then using DS the proxy unregistration will result in the unbind method above being called by DS.
But the two requirements on the distribution system above may not be satisfied by all distribution providers. For example, for a typical REST/http-based service, there may be no way for the distribution system to detect network failure, and so no unbinding of the service can/will occur.

The use of transport-independent remote services, along with the ability to choose/use/create custom distribution providers as appropriate allows micro service developers to easily deal with the realities of distributed computing, as well as changing service requirements.

IoT Standards and Remote Services

In a recent posting, Ian Skerrit asks:   Can open source solve the too-many standards problem?

Even though it's clear that IoT developers want interoperability (the putative reason for many communications standards), there are other reasons that lead to multiple competing standards efforts (e.g. technical NIH, desire for emerging market dominance, different layering, etc).

I agree with Ian that open source provides one way out of this problem, as open implementations can provide interoperability much more quickly than formal standardization efforts.   One doesn't have to look very far to see that's been the case for previous communication and software standards efforts.

One complication for the IoT developer, however, is that they frequently need to make a choice...so that they can build their applications.   This choice has risks, however, because if the communications protocol one chooses doesn't end up being widely adopted/popular, does not provide interoperability with the necessary systems, or is a poor fit to the application-level or non-functional needs for your app (e.g. performance/bw requirements, round-trips, etc), then it could mean a very costly re-architecture and/or re-implementation of one's app or service.  

One way to hedge this risk is provided by ECF's implementation of Remote Services.   OSGi Remote Services is a simple specification for exposing an arbitrary service for remote access,   The spec says nothing about how the communication is done (protocol, messaging pattern, serialization), but rather identifies a pluggable distribution provider role that must be present for a remote service to be exported.   Each service can be exported with a distinct distribution provider, and the decision about what provider is to be used is done at service registration time.

One effect of this is that the remote service can be declared, implemented, tested, deployed, used, and versioned without ever binding to a distribution system.   In fact, it's possible to use one distribution provider to develop and test a remote service, and deploy with a completely different distribution provider simply by changing the values of some service properties.   With ECF's implementation, it's easy to either use an existing distribution provider, or create your own (open source or not), using your favorite communications framework.

ECF Remote Services allows IoT developers maximum flexibility to meet their application's technical needs, now and in the future, without having to commit permanently to a single communication framework, transport, or standard.

Transport-Independent Remote Services

ECF recently released version 3.13.1 of it's implementation of the OSGi Remote Services and Remote Service Admin specifications.

Over the past year, we have made it easier for us and others to create custom distribution providers.   This has made it possible to quickly create a variety of open source distribution providers...for example, HTTP/HTTP/REST/Jax-RS implementations, TCP, Hazelcast, JMS, AMQP, MQTT and JavaGroups) as well as others.

Why is this useful and important?   In my view, it's important because it allows service developers to define, implement, deploy and maintain transport-independent Remote Services.   Transport-independence gives the flexibility to address changing requirements without the need to alter the service or it's implementation.

For example, consider a small remote service for accessing a simple data set.   Ideally, the service interface, implementation, and client would use one distribution system/transport for all time for the life of the service.   In practice, however, it's often necessary to respond to changing funtional and non-functional transport-related requirements...for example requirements for interoperability/integration, changing security requirements, network performance requirements, bandwidth, service availability requirements, the need to take advantage of new protocols (e.g. MQTT, COAP, Iot.), etc.

This new tutorial shows how Remote Services can be declared, implemented, deployed, and versioned without any dependencies on the underlying distribution system or transport.   Pluggable distribution providers may be substituted with no service or application-level code changes.   This is accomplished by adherence to standards (OSGi Services/Remote Services and Jax-RS) as well as ECF's pluggable distribution provider approach.

The costs of open source maintenance

Another very interesting story about Heartbleed/OpenSSL...wrt maintenance and support

• Who Should Pay to Keep the Internet's Locks Secure