M
M van Leeuwen
Dear community,
I'm in the process of designing a service oriented architecture in which
certain business processes are exposed to the world through services.
My requirements are as follows:
* Services are exposed via EJBs, WebServices and JMS and available
for any type of client (C++, dotNet, PHP, Java).
* Versioning is an important issue. Old versions are to be supported
for at least 12 months after notice. New versions must seamlessly
put available for users.
* Users must be notified the service is deprecated without breaking
functionality
* The content of the servicemessage (not the wrapping envelope) should
use a definition equal amongst the exposure methods.
* Security must be applied
* Based on the user role, the response must be filtered from confidential
information.
* New versions of the implementation (without changing the interface)
must be made possible at least every month.
* Internationalisation should be supported.
To make it easier for the client, I suggested a non versioned service
routing to the versioned counterpart based on a client specified version.
Implementation thus has the possibility to remove older versions and
replace them for functional equal new versions.
To add language, version and messages, a wrapper can be used around the
object in the servicecall/response. This can also be used for functional
errors.
My thought was: use XML. Not in the WebServices style in which the XSD
is inside the WSDL, but the business objects from the business processes
are first translated to XML, adding metadata, and then transported using
EJBs, JMS or WS. The client then uses the XML for further 'processing'.
Filtering should be easy, routing should be easy, mapping the BOs to XML
should be easy (using Betwixt). It is mighty flexible and versioning does
not deliver any problems (no new client-ejb-jars, no need to reread the
WSDL). Just increase the version inside the message, and expect results
according to the new definition. Exposing definition is easy (XSD).
Questions:
* What's your opinion?
* Are there any common practices other than this?
* Who is using this variant?
* Any additions, advices?
Many thanks in advance!
Kind regards,
Michael.
I'm in the process of designing a service oriented architecture in which
certain business processes are exposed to the world through services.
My requirements are as follows:
* Services are exposed via EJBs, WebServices and JMS and available
for any type of client (C++, dotNet, PHP, Java).
* Versioning is an important issue. Old versions are to be supported
for at least 12 months after notice. New versions must seamlessly
put available for users.
* Users must be notified the service is deprecated without breaking
functionality
* The content of the servicemessage (not the wrapping envelope) should
use a definition equal amongst the exposure methods.
* Security must be applied
* Based on the user role, the response must be filtered from confidential
information.
* New versions of the implementation (without changing the interface)
must be made possible at least every month.
* Internationalisation should be supported.
To make it easier for the client, I suggested a non versioned service
routing to the versioned counterpart based on a client specified version.
Implementation thus has the possibility to remove older versions and
replace them for functional equal new versions.
To add language, version and messages, a wrapper can be used around the
object in the servicecall/response. This can also be used for functional
errors.
My thought was: use XML. Not in the WebServices style in which the XSD
is inside the WSDL, but the business objects from the business processes
are first translated to XML, adding metadata, and then transported using
EJBs, JMS or WS. The client then uses the XML for further 'processing'.
Filtering should be easy, routing should be easy, mapping the BOs to XML
should be easy (using Betwixt). It is mighty flexible and versioning does
not deliver any problems (no new client-ejb-jars, no need to reread the
WSDL). Just increase the version inside the message, and expect results
according to the new definition. Exposing definition is easy (XSD).
Questions:
* What's your opinion?
* Are there any common practices other than this?
* Who is using this variant?
* Any additions, advices?
Many thanks in advance!
Kind regards,
Michael.