سرویس چیست؟
سرویس یکی از اجزای نرم افزاری می باشد که خصوصیات زیر را دارد:
1. با یک واسط مستقل از پلت فرم تعریف شده است.
2. از راه اینترنت قابل استفاده می باشد.
3. عملکرد آن به گونه ای است که business function ها را توسط business object ها اجرا می کند.
4. واسط و اجرای آن به گونه ای نشانه گذاری می شود که در زمان اجرا به بهبود عملکرد بیانجامد.

سرویس می تواند معانی دیگری نیز داشته باشد، گاه معنای آن وسیع تر است، برای مثال یک جز توزیع شده که واسط آن با کسب و کار طراحی شده است. گاهی معنای آن جزئی تر می باشد مانند وب سرویس مبتنی بر SOAP .
ابتدایی ترین مشکل برای پیاده سازی SOA این است که اکثریت با مفهوم اصلی ساختمان بلوکه ای، یعنی همان سرویس، موافق نیستند. بسیاری از تعارف سرویس، به مفاهیم بی ثبات و مختصر اشاره دارند، مانند قابلیت انعطاف پذیری و چابکی که برای برنامه نویسان بسیار مبهم می باشد.
به جرأت می توان گفت، هیچکس در انتخاب نمی خواهد یک نرم افزار غیرقابل انعطاف و کند که نیازهای عملی را برآورده نمی سازد خلق کند. اما در واقعیت برخلاف کوشش های زیاد اغلب این اتفاق رخ می دهد. دانستن اینکه SOA می تواند سازگاری و چابکی به ارمغان بیاورد ستودنی است اما این به تنهایی کمک کننده نیست.
تمامی تعاریف دیگر برای دنیای واقعی خیلی جزئی تر می باشند، برای مثال: تعیین کردن اینکه سرویس باید جزئی از نرم افزار باشد که زبانش SOAP است می تواند گمراه کننده باشد. اما این یک محدودیت ساختگی است، اشخاص زیادی هستند که از REST استفاده می کنند و فکر می کنند که در حال ارائه سرویس هستند. شاید بهتر است که تعریف ما شامل چیزهایی درباره پیام های مبتنی بر XML که تفاوت بین RESTfull webservice و SOAP-Based service را به وجود می آورند، باشد. اما باز هم یک محدودیت برای تعریف کلی ما به حساب می آید.
چگونه به یک تعریف جامع و خاص برای سرویس دست پیدا کنیم که برای اهداف متنوع سرویس در دنیای واقعی پذیرفتنی باشد؟
بهتر است تمامی جنبه های تعریف سرویس را پیش از اینکه بیشتر پیش رویم، بررسی کنیم.

واسط مستقل از نرم افزار
کاری که یک سرویس می تواند انجام دهد باید با یک واسط خارجی شرح داده شود. برخی از معماران نرم افزار اجازه می دهند که سرویس آنها فقط با یک پلت فرم خاص اجرا شود، مانند رابط جاوا که اجرا را فقط روی remote session EJB امکان پذیر می کند. سرویس ها حتماً از این روش به معنای خود نزدیکتر می شوند و نزدیک شدن به این مفهوم در میان بافت کسب و کار موردنظر محقق می شود. دستور دادن به اینکه مصرف کننده باید از یک پلت فرم مشخص مانند جاوا یا دات نت برای دریافت سرویس استفاده کند می تواند زمان و هزینه قابل توجهی را صرفه جویی نماید و به طور موثر اعمال اجرایی را ساده کند.
خیلی از کاربردهای معماری سرویس گرا در یک شرکت و در پشت یک سیستم حفاظتی و در یک محیط شناخته شده نسبتاً ایستا عمل می کنند. معماران زیادی وجود دارند که مفهوم SOA را در پلت فرم EJB که یک پلت فرم بسیار خاص می باشد پیاده سازی کرده اند. در حالی که پیاده سازی در یک پلت فرم خاص، ما را به اهداف SOA نمی رساند هر چند این عمل بسیار هوشمندانه و با تجربه صورت پذیرد.
WSDL ها از SOAP در HTTP استفاده می کنند. HTTP ممکن است یک لایه مناسب انتقال برای سرویس های تحت وب نباشد اما سادگی و قابلیت نفوذ آن باعث انتخاب آن به عنوان لایه پیش فرض می باشد. در نتیجه پشتیبانی قابل توجهی برای اجرای این نوع سرویس ها وجود دارد.
وب سرویس های RESTful از متدهای HTTP و زبان XML برای تعریف واسط های خود استفاده می کند و این رویکرد پشتیبان بسیاری دارد که از پیچیدگی و بزرگ بودن سرویس هایی تحت SOAP خیلی راضی نیستند.
سرویس فقط، یک قسمت از کارکرد اصلی نمی باشد بلکه چیزی است قابل توصیف با یک قرارداد که روی مصرف کننده ها متمرکز هستند، بنابراین این مهم است که یک واسط تعریف شده و مشخص با قرارداد خودکارسازی کار کند. بدون داشتن یک واسط مشخص، از قابلیت استفاده مجدد سرویس کاسته می شود. بدون استقلال سرویس، نارضایتی مشتریان و وابستگی بیش از حد را در پیش داریم.