Thomas Erl, who edits the research journal SOA Magazine and the SOA Systems technical books series for Prentiss-Hall, is contributing intellectual property governing the modeling of web services. The service modeling content is being contributed to Red Hat, which will administer the patents and make the intellectual property available to open source developers.
Erl’s approach categorizes web services as entity, task, and utility services.
Entity services are representations of business objects or entities, such as customer, employee, invoice, and claim. Entity services are considered potentially highly reusable because they don’t represent business processes, but instead cover the objects or entities that are consumed by them. From a linguistic standpoint, business entities are nouns.
Task services have a closer relationship to business process or automated workflow, in that these are tangible activities that utilize business logic to perform a sequence of steps. An example could include an invoice service that utilizes an entity, which could be invoice and customer, and perform series of tasks to ensure that invoices are sent to customers.
Finally, utility services are system-level services that deal more with system plumbing than business processes themselves. Examples include event logging, notification, and exception handling, and are considered totally independent of the process or application.
JBoss is adding this to its SOA platform, and will host an open source project that expands on Erl’s definitions.
Our View
This is JBoss’s answer to IBM’s Service-Oriented Modeling Architecture (SOMA), which extends component-oriented modeling principles by helping organization’s inventory what software components are already available to expose as web services, and what key performance indicators (KPIs) might be associated with them. Initially developed with business processes in mind, IBM earlier this year broadened its SOMA models to data services as well. Clearly, JBoss is playing catch-up as its service modeling architecture is less developed.
But in the long run, the goal of all these service modeling efforts is to apply the same rigors that have accompanied enterprise software development to web services. The idea is that services shouldn’t be exposed just because they are there. Ultimately, service modeling may face competition from BPM users such as business analysts and process owners, as they perceive service modeling as a way to steal their thunder.
It eventually boils down to the question, who defines the service: the application developer or the business process owner. The introduction of service modeling adds yet another battleground in the continuing tug of war between BPM users and SOA project teams, and provides another place where enterprise architects may have to play arbiter.
