member login

WebServices dot org

Todays Featured Content:

Active Endpoints Ships First Open-Source System to Include People in Composite Applications

New BPEL4People and WS-Human Task specifications to eliminate proprietary workflow, speed delivery of services-based applications

Product Information: ActiveBPEL Enterprise Data Sheet

ActiveBPEL™ Enterprise is the premier solution for deploying, running and managing applications based on the BPEL standard, designed from the ground up with a modular, extensible architecture...

Product Information: ActiveBPEL Designer Data Sheet

ActiveBPEL™ Designer is an integrated environment for rapidly building, testing and deploying applications based on the BPEL standard...

The R.O.I. of Composite Applications

SOA and composite applications hold out the promise for ease of use and lower training costs, lower cost of deployment, faster time to market, improved business requirement matching and better multi-channel deployment.
Learn more in this white paper.

Featured Content provided by Active Endpoints

Formal Definitions

18th Jan 06:

I haven't seen any formal definition of SOA and I don't think there is any. As there is no (afaik) formal definition of the term 'enterprise architecture'.

At least formal in the sense Mark and Patrick are talking about.

As far as 'formalism', I like Don's classic service orientation fundamentals . Others (e.g. Systinet) add some extra stuff like Registry as the architectural element of SOA. I like Registry-based SOA because I like Don's fundamentals and I believe Registry-based (or repository depending of your level of sophistication) SOA is perfectly aligned with them. But somebody else likes ESB, others are ok with EAI MOMs... There is no way to reach a formal agreement. Actually, I don't even think there is a need to do so.

Web Services (WS-*/WSDL) Architecture is imho different animal. It can be formally described and its description would be very similar to CORBA (in its very core). Web services are still better choice than CORBA in most cases because CORBA was created at times when people believed middleware vendors have solution for all EAI problems. This resulted in heavyweight mastodon. So we have an example of two technologies that share most of architectural characteristics - yet their usability is very different.

I believe SOA Governance can help shaping the SOA over time by imposing constraints over services. For example limiting MEPs, mandating richer metadata (e.g. more policies), or REST - which is where you should go for in case of complex systems.

Reprinted from Radovan Janecek: Nothing Impersonal .


Trackback URL for this post: http://www.webservices.org/trackback/id/71841

Comments