You can add transport bindings to your reusable services iteratively as necessitated by project needs and timelines. A service can start out getting consumed over HTTP, and then support additional ones such as HTTP-S and JMS over time. The key is to not place transport logic in your service capability. This will give you a great deal of flexibility in adding and supporting new transports.
For example, your service can be initially consumed by a user interface application via request/reply SOAP over HTTP. Day 2, you might have a backend process that consumes the service via asynchronous request/reply SOAP over JMS. This should be a graceful extension for you if there was nothing in the service logic specific to HTTP or synchronous request/reply.
In essence, you are decoupling request processing, service business logic, and response handling: