-
Notifications
You must be signed in to change notification settings - Fork 616
Protocol Buffers
Protocol Buffers is one of the three available channels to access the methods of the Service Interfaces.
As the BIMserver's main function is to allow other software to store and retrieve information about building information models, it is very important to support a wide variety of programming languages. From the beginning of the BIMserver project a SOAP interface has been available, but SOAP has a few disadvantages:
- SOAP is XML based, which makes it slower/larger
- Almost every SOAP stack interprets the standards a little different
- A lot of diversions/extensions are available, excluding certain soap clients
For these reasons another interface has been implemented: Protocol Buffers.
The Protocol Buffers API maps all the functions available in the services [LINK], so the actual calls will not be described in this document.
The .proto file can be downloaded from a running BIMserver. Go to the "Info" page and click on the "Web Services" tab, then download the "Protocol Buffers Descriptor File". With this .proto file you can generate the service interface and messages for a wide range of programming languages, please check out the Protocol Buffers website for more details.
The "service interface" methods are not available in the Protocol Buffers API as-is because PB does have some limitations.
All service calls in Protocol Buffers allow only 1 parameter and 1 return type, for this reason the BIMserver generates specific "Request" and "Response" messages for every call. For example the login
method uses the LoginRequest
message as input parameter, and the LoginResponse
message as the return type.
All request messages contain the same amount of fields as there are parameters in the service call. So for the login method, the LoginRequest
message contains 2 fields: username
and password
, both of type string
.
All response messages contain 2 fields. The first field is the errorMessage
field of type string
. This field always contains "OKE"
if the call succeeded, or something else describing the error if the call did not succeed. The reason for this construction is the fact that Protocol Buffers does not support Exceptions, but the "service interface" does throw them. The BIMserver converts the exceptions thrown to errorMessage values.
The second field is the actual return value. This is always the same value as in the ServiceInterface, or unset if an error occured. The special Void
type is used for return-type-less methods.
Protocol Buffers is only a message format, the actual transport method can be chosen by the developer. We have chosen to use Protobuf Socket RPC. This implementation only provides a Java and Python version for now, but as the implementation is pretty straight-forward other languages could be used without too much hassle.
Get Started
- Quick Guide
- Requirements Version 1.2
- Requirements Version 1.3
- Requirements Version 1.4
- Requirements Version 1.4 > 2015-09-12
- Requirements Version 1.5
- Download
- JAR Starter
- Setup
Deployment
- Ubuntu installation 1.3
- Windows installation
- Security
- Memory Usage
- More memory
- Performance statistics
- Large databases
Developers
- Service Interfaces
- Common functions
- Data Model
- Low Level Calls
- Endpoints
Clients
BIMServer Developers
- Plugins in 1.5
- Plugin Development
- Eclipse
- Eclipse Modeling Framework
- Embedding
- Terminology
- Database/Versioning
- IFC STEP Encoding
- Communication
- Global changes in 1.5
- Writing a service
- Services/Notifications
- BIMserver 1.5 Developers
- Extended data
- Extended data schema
- Object IDM
New developments
- New remote service interface
- Plugins new
- Deprecated
- New query language
- Visual query language
- Reorganizing BIMserver JavaScript API
General