Service Archive

[Dennis Reedy]

I've been thinking that perhaps in order to simplify the signature and the multitude of configuration parameters that we adopt the idea of using a JAR manifest to contain immutable service configuration attributes. You may have recalled discussions on the Jini list a while back about service archives, I think this notion fits well into what we're looking at here.

With the service archive (SAR), we would have a JAR (with a .sar extension) that contains manifest attributes of:

Service-Classpath

Service-CodebaseClasspath

Service-ImplClass

Service-InterfaceClass

(*)Service-Probes

(*)Service-Configuration

Are there other immutable attributes?

Using the SAR would replace the following declaration(s) and simplify the environment that developers would need to setup

service(name:"foo") {

    interfaces {

        classes "Foo"

        artifact

    }

    implementation(class:'FooImpl') {

        artifact

    }

    maintain 1

}

Instead, when using a SAR, a service declaration may look like:

service(name:"foo") {

    archive "com.foo:bar:sar:1.0"

    maintain 1

}

The SAR would not contain other jars, or be the main jar, it would be an additional artifact produced and referenced in the opstring. The SAR may optionally contain a configuration file loadable as a resource though. 

Thoughts?

Regards

Dennis

(*) Optional

[Rafał Krupiński]

On 16.10.2013 15:01, Dennis Reedy wrote:
> I've been thinking that perhaps in order to simplify the signature and
> the multitude of configuration parameters that we adopt the idea of
> using a JAR manifest to contain immutable service configuration
> attributes. You may have recalled discussions on the Jini list a while
> back about service archives, I think this notion fits well into what
> we're looking at here.
>
> With the service archive (SAR), we would have a JAR (with a .sar
> extension) that contains manifest attributes of:
>
> Service-Classpath
> Service-CodebaseClasspath
> Service-ImplClass
> Service-InterfaceClass
> (*)Service-Probes
> (*)Service-Configuration

Hi Dennis

+1 for splitting immutable and mutable configuration parts.

Do you indent to make it compatible with future versions of River?
What about Service-(Codebase)Classpath format (file name vs http:// vs
artifact://) and transitional dependencies?

We had an idea to make deployment jars, that would only contain an
opstring, service configuration and a pom.xml referencing the actual
service artifacts. This way we could write opstrings that refer to
configuration files by classpath URL withoud mixing configuration and
code within the same jar.
Anyway, I see some convergence here :)

Regards
Rafał

[Dennis Reedy]

On Oct 16, 2013, at 934AM, Rafał Krupiński wrote:

> On 16.10.2013 15:01, Dennis Reedy wrote:
>> I've been thinking that perhaps in order to simplify the signature and
>> the multitude of configuration parameters that we adopt the idea of
>> using a JAR manifest to contain immutable service configuration
>> attributes. You may have recalled discussions on the Jini list a while
>> back about service archives, I think this notion fits well into what
>> we're looking at here.
>>
>> With the service archive (SAR), we would have a JAR (with a .sar
>> extension) that contains manifest attributes of:
>>
>> Service-Classpath
>> Service-CodebaseClasspath
>> Service-ImplClass
>> Service-InterfaceClass
>> (*)Service-Probes
>> (*)Service-Configuration
>
> Hi Dennis
>
> +1 for splitting immutable and mutable configuration parts.
>
> Do you indent to make it compatible with future versions of River?

I have no idea what the future versions of River may or may not include.

> What about Service-(Codebase)Classpath format (file name vs http:// vs artifact://) and transitional dependencies?

If the codebase/classpath is an artifact then dependencies and transitive dependencies will be resolved. This is the same way it is done today by declaring the artifact for the codebase and classpath for a service. The same thing would happen here.

In the case of jars, the intent is to have a comma-separted list of jars whose http:// address would be obtained from the declaration in the opstring.

>
> We had an idea to make deployment jars, that would only contain an opstring, service configuration and a pom.xml referencing the actual service artifacts.

In Rio this is called an Operational String Archive (OAR). The OAR contains everything you mention (sans a configuration). I recommend you look into using that instead of creating something new.

Regards

Dennis

[Rafał Krupiński]

Why OAR doesn't contain the service configuration file? It seems sensible, that you put static configuration (like classpath, class you've mentioned in the first post) in the manifest of service jar and mutable (instance) configuration to some container external to the jar, like oar.

Rafał