It's All in a Name: What's a Service?

re: It's All in a Name: What's a Service?

Dave Donaldson — Fri, 12 Mar 2004 07:55:00 GMT

Pat,

Glad to have you aboard. I saw you present at the PDC in October (I continue to refer people to your slide deck every so often when in heated discussions of services). Looking forward to your thoughts and insight as time goes on.

Pat Helland is blogging

Nothing But XML InfoSet — Sun, 14 Mar 2004 10:39:00 GMT

Pat Helland starts blogging. I have been respecting him since when I first hear him talk at TechEd (2000 IIRC) about Fiefdom and Emissary.

re: It's All in a Name: What's a Service?

Paul Gielens — Mon, 15 Mar 2004 22:25:00 GMT

http://weblogs.asp.net/pgielens/archive/2004/03/15/89919.aspx

Pat, welcome

re: It's All in a Name: What's a Service?

Marcus Mac Innes — Tue, 16 Mar 2004 17:38:00 GMT

Pat, absolutely great presentation at the PDC!

I’ve got a question regarding your description above using foos and bars to differentiate between service interfaces and a completely autonomous service. In the talk which immediately followed yours at the PDC, David Campbell spoke about Service Agents and Service Masters. In terms of foos or bars, what “type” of services are these?

Service Oriented Architecture - What is a service?

Marcus Mac Innes' Blog — Tue, 16 Mar 2004 17:39:00 GMT

re: It's All in a Name: What's a Service?

Jean-Jacques Dubray — Sat, 20 Mar 2004 00:33:00 GMT

Pat:

I like your thoughts on foos and bars but I have a question about bars. Since bars are autonomous from a data perspective, how do you deal with the fact that business applications rely on a data model that is completety intertwined and related. For every type of systems (ERP, CRM, PLM, HR, SCM,...) there are usually one or more centers of the data model and all the other tables, without a single exceptions are related. As a matter of fact, within an enterprise very few pieces of data are independent (I could only think of HR and everything else). Does that mean that a bar is as big as an ERP or CRM system?

thanks,

JJ-

re: It's All in a Name: What's a Service?

Luke Stevens — Thu, 25 Mar 2004 01:45:00 GMT

Is the difference between a service and a service interface any more substantial than the difference between a circle—in the sense of a solid filled circularly shaped area—and the boundary of that circle, also known as a circle?

re: It's All in a Name: What's a Service?

Pat Helland — Sun, 04 Apr 2004 03:35:00 GMT

Re: http://blogs.msdn.com/pathelland/archive/2004/03/11/88058.aspx#92937">http://blogs.msdn.com/pathelland/archive/2004/03/11/88058.aspx#92937

re: It's All in a Name: What's a Service? 3/19/2004 5:33 PM Jean-Jacques Dubray

JJ asked about the fact that MANY enterprise systems end up with their data being accessed by many different apps and there ending up with no clear boundaries.

See: http://blogs.msdn.com/pathelland/archive/2004/03/11/88058.aspx#92937">http://blogs.msdn.com/pathelland/archive/2004/03/11/88058.aspx#92937

Great question! I think the issue is that many apps have created the “Big Ball of Mud” as described by Brian Foote and Joseph Yoder (see http://laputan.org/mud/mud.html)

It is natural to get everything complete entwined when you can just open the database table and get to the data you want. The easy thing happens and soon every application on the system is sharing one humongous data model. One of the driving forces of SOA is to emphasize a new and coarser encapsulation.

Objects do encapsulation just fine to protect member variable… indeed, the object folks (as a sweeping generality) think about in-memory data and encapsulation but don’t think about the fact that real data (i.e. enterprise data) is kept in a database. This leads to a programming environment where many different objects would open up the database tables and whack on the data contained within them.

Sure, during the execution of a transaction their member variables are encapsulated but database records are effectively global variables unless we impose some discipline on them.

The way I think about SOA is that the service (or the “bar” if you will) is a scoping of these “global variables” to live within disjoint sets (which I have jokingly labeled as “bars”).

So, is a bar as big as an ERP or CRM system?

In the future, we will see new systems defined to understand that some data is published by one service as read-only snapshots of data (which I frequently call reference data). For example, the Accounts-Receivable package will definitely need to refer to the customer information and have an identity for the customer. It is likely that changes to the customer data only happen at the CRM system and are periodically published as a version of the customer info (e.g. Tuesday’s customer-info, Wednesday’s customer-info). This is a modeling abstraction for how data is handled across multiple services that acknowledges the need for passing out copies of information (to other services) that understand it is not absolutely the freshest state. This is inevitable as systems are designed to be more independent and yet interact together.
Many of today’s enterprise apps are not designed with this in mind. They were developed for environments in which it was OK to open another apps table in the shared database (perhaps only open it for read-only access but still open it directly). This allowed the app to see the up-to-date and accurate state of affairs as of the last transaction. This is a different semantic than the read-only snapshot version that is sent out periodically.

Many of today’s apps will not get broken apart because it is too hard and too expensive. That is OK. They will continue to exist but will not get the scale-out benefits that are possible with an SOA designed app and will perhaps be more challenging to maintain.

Still, you can surround these apps with service-based interfaces using messages coming in and out. I’ve said before that it is frequently a great idea to export only a subset of the functionality that makes business sense to creating message-based interfaces for. This will mean that many (pre-SOA) apps (e.g. ERP, CRM, etc) will be very large services. Indeed, they will be very large services with some work arriving via service interaction (where it makes business sense to retrofit the app to cope with certain functions arriving via messaging) and other work directly arriving from human operators the way it always did because there was no business justification to change those interfaces to the app. Only do programming when it makes business sense.

In freshly designed apps, smaller grained services will be created. The ERP system may comprise dozens of services. This is practical when you are designing it in from the beginning. It is far less likely for an app that was not designed to have the data kept separate into different “bars”.

So the answer is “it depends” and over time, more and more boundaries will appear. It is the creation of programmatic models to encourage this evolution that is one of the major goals of SOA.

Love,
Pat

re: It's All in a Name: What's a Service?

Jean-Jacques Dubray — Sun, 11 Apr 2004 21:16:00 GMT

Pat:

thanks, I saw your presentation on MSDN, what a great string of presentations from Norm et al. This is great stuff. I can sense a bit of hand waving in your answer here, but that's ok, this was a very difficult question, probably a billion dollar question. OAGIS did define some clear boundaries already and I have a lot of respect for an architecture that was concieved in 1995 and is becoming more relevant on a dayly basis.

I am having a debate on my blog related to this question (so the question was not completely innocent), I argue that model-oriented business logic (i.e. the bars services) must be orchestrated, rather than request/response invoked by a BPEL process.

My argument is basically that "BPM" greatly impacts the "controller" of MVC, but that's not enough. It is clear that the view is also impacted (e.g. UIP application pattern). I also content that the model needs to be orchestrated to avoid spaghetti business processes. An orchestrated model reflects far better the lifecycle of business entities like Orders or Invoices, while the process can decide rules and steps that advance this lifecycle.

Part of the debate is at: http://www.ebpml.org/bpel-j.htm

Since you have been the father of COM+ and MTS, I might as well ask you another question I keep asking on my blog. What about creating a Microsoft Coordination Server (on top of Indigo for instance). Where all forms of coordination could live (transaction, orchestration, ...)

Cheers,

Jean-Jacques Dubray
Architect, Attachmate

SOA Information Hub

Kirk Allen Evans' Blog — Wed, 28 Apr 2004 00:12:00 GMT

re: It's All in a Name: What's a Service?

dianying xia zai — Sun, 01 Aug 2004 18:09:00 GMT

http://www.dmoz.net.cn/ wangzhidaquang
http://www.86dmoz.com/ jingpingwangzhi
http://www.kamun.com/ mianfeidianying
http://movie.kamun.com/ dianyingxiazai
http://music.kamun.com/ MP3 free download
http://www.pc530.net/ diannaoaihaozhe
http://www.5icc.com/ duangxingcaixingxiazha
http://www.dianyingxiazai.com/ dianyingxiazai
http://www.yinyuexiazai.com/ yinyuexiazai

PatHelland s WebLog It s All in a Name What s a Service | Patio Chairs

PatHelland s WebLog It s All in a Name What s a Service | Patio Chairs — Wed, 03 Jun 2009 05:43:00 GMT

PingBack from http://patiochairsite.info/story.php?id=26749

PatHelland s WebLog It s All in a Name What s a Service | Insomnia Cure

PatHelland s WebLog It s All in a Name What s a Service | Insomnia Cure — Wed, 10 Jun 2009 03:33:37 GMT

PingBack from http://insomniacuresite.info/story.php?id=4156

PatHelland s WebLog It s All in a Name What s a Service | patio set

PatHelland s WebLog It s All in a Name What s a Service | patio set — Sun, 14 Jun 2009 20:04:31 GMT

PingBack from http://patiosetsite.info/story.php?id=1

PatHelland s WebLog It s All in a Name What s a Service | alternative dating

PatHelland s WebLog It s All in a Name What s a Service | alternative dating — Wed, 17 Jun 2009 10:17:18 GMT

PingBack from http://topalternativedating.info/story.php?id=1373

PatHelland s WebLog It s All in a Name What s a Service | patio umbrella

PatHelland s WebLog It s All in a Name What s a Service | patio umbrella — Thu, 18 Jun 2009 07:05:58 GMT

PingBack from http://patioumbrellasource.info/story.php?id=1775

PatHelland s WebLog It s All in a Name What s a Service | bar stools

PatHelland s WebLog It s All in a Name What s a Service | bar stools — Fri, 19 Jun 2009 09:45:14 GMT

PingBack from http://barstoolsite.info/story.php?id=57

PatHelland s WebLog It s All in a Name What s a Service | garden decor

PatHelland s WebLog It s All in a Name What s a Service | garden decor — Fri, 19 Jun 2009 10:21:19 GMT

PingBack from http://gardendecordesign.info/story.php?id=5169

PatHelland s WebLog It s All in a Name What s a Service | adirondack chairs

PatHelland s WebLog It s All in a Name What s a Service | adirondack chairs — Fri, 19 Jun 2009 12:04:26 GMT

PingBack from http://adirondackchairshub.info/story.php?id=1413

PatHelland s WebLog It s All in a Name What s a Service | patio cushions

PatHelland s WebLog It s All in a Name What s a Service | patio cushions — Fri, 19 Jun 2009 13:06:27 GMT

PingBack from http://patiocushionsource.info/story.php?id=229