Publishing and forking environments
About environments: The SOA model embedded in EasySOA aims at supporting several "environments", i.e. several versions of the SOA deployed at different places for different purposes. In most cases, we would have the staging or production environment that will serve as a reference ("Master" environment), and various developer environments, that contain a subset of the SOA services, that replace real services by mocks for testing, etc.
The first document level under the "Service Registry" consists of workspaces. Each one matches an environment we're working on. Each workspace can be "published", meaning that we'll take a snapshot of the SOA model and consider it's the existing one (in the future, we'll work on being able to actually deploy services).
In order to do that, just browse to the workspace you want to publish, and click the "Publish workspace" button:
The published services can now be found under the "Environment" node (you might need to presh "refresh").
In order to ease the SOA evolutions, we introduced the idea of "forking" an environment. This allows to create a brand new workspace based on any published environment: just browse to the root of any environment and press the "Fork workspace" button.
You'll then find a workspace with your username as title, that contain everything from the reference environment (you might need to presh "refresh" to see it). See it as a developer environment that clones the existing one to let you work on it.
Each application has a button "Update from reference App" that allows to fetch again an updated version of the services from the reference environment.
The model creates links between the new services and the forked ones, storing the later as references: this will mainly allow for validating compatibility between the new and existing versions of each service (See SOA sanity check dashboard).