Member Avatar for Curious Gorge

I want to develop a piece of software that other developers can use in their projects. It has to be active at runtime however, and perform some standard functionality every time the application runs. It is essentially software that provides extra functionality to the application developer and its users...

I'm not sure how I might do this, and my google-fu has not been strong enough to find a definite answer.

  • 4 Contributors
  • 3 Replies
  • 5K Views
  • 3 Months Discussion Span
  • Latest Post Latest Post by bngwebguru
Sunny_18 commented: I think that your problem is that you have not added the .jar files to your classpath. Setting environment variables and using the correct import stat +0

Dani AI

Generated

At a high level you have two delivery models, each with different trade-offs:

  • Embeddable SDK/library: linked into the host app. Lowest latency and easiest local state sharing, but you must ship per-language bindings and manage dependency/version conflicts.
  • Out-of-process service/daemon: a small process the app calls over HTTP/gRPC. This matches what rproffitt hints at and works from any language. It adds deployment and network concerns, but centralizes updates and isolates failures. JamesCherrill’s API-with-optional-GUI idea fits either model.

Whichever you choose, define a crisp runtime contract and treat it as a product:

  • Minimal lifecycle: init -> handle requests -> shutdown (with timeouts and idempotency).
interface RuntimeExtension {
  void initialize(Config cfg);
  Result handle(Request req);
  void shutdown();
}
  • Stable, versioned surface; follow Semantic Versioning.
  • Transport/packaging: for services prefer HTTP+JSON or gRPC with explicit schemas; for SDKs publish to the ecosystem’s registry (Maven/NuGet/npm/PyPI).
  • Configuration via environment variables and files, not code changes; see The Twelve-Factor App.
  • Security: authenticate service calls (tokens/MTLS), validate inputs, and avoid logging secrets (see OWASP Top 10 at https://owasp.org/www-project-top-ten/).
  • Observability: structured logs, metrics, and traces (e.g., OpenTelemetry).
  • Compatibility tests: contract tests to catch breaking changes; deprecate before removing.

Start with a thin API, instrument it well, and iterate with real integrators before expanding scope.

Recommended Answers

All 3 Replies

Member Avatar for rproffitt

A little light on details but here's a trick I used long ago. To make a service available to just about any language app I set it up as a miniature server or service. You would connect to it via IP, send your query string much like SQL and the answer would come back on the same pipe.

Whether this applies or not is something I can't guess given what has been revealed so far.

Member Avatar for JamesCherrill

How about something to manage Users... logon, password verification, privileges/authorisations, preferences etc
You could have it as a API then optionally layer a GUI on top.

Member Avatar for bngwebguru

Define Your Site’s Purpose and Strategy
Research the Latest Web Design Trends
Choose Your Platform
Select a Template and Start Customizing
Decide on Your Branding
Add In and Optimize Your Content
Publish Your Website
Analyze and Improve

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.