0

I have seen quite a lot of instances where the term "Web Services" & "Service Oriented Architecture - SOA", have been used interchangeably. But, I am sure a lot of you would agree that they are just not the same, where "SOA" is way beyond and a lot more than just "Web Services"!

Nevertheless, going to my question(s), being a small company that we are as of now, we have this new business to provide a bunch of web services - to external clients (other companies). So, I have the following questions in mind, in this regard:

1) Should we just concentrate on developing these bunch of web services (Java, Spring) and deploying them independently and deliver to the clients to begin with, or should we also consider bringing them all together and providing means for web service governance by using SOA infrastructures like Mule ESB, Apache ServiceMix, etc.

2) Is it a lot easier and less resource-intensive (effort-wise and money-wise) to consider SOA infrastructure right from the beginning or is it going to be almost the same even if we defer it to sometime later? I just want to make sure that we do not over-engineer and so I am not sure if SOA is an over-kill or it really worth the time and investment, from the beginning?

3) Do SOA infrastructures offer better performance with High Scalability and Low Latency, as compared to deploying the web services independently just like any web application? I sometimes wonder that doesn't all this additional infrastructure for SOA add to latency?

4) I have heard of several SOA infrastructures like Apache ServiceMix and Mule ESB, which I guess are open-source while there are other licensed solutions like the Oracle SOA suite, and IBM DataPower. Are they all equally good or is there any best choice? I also wonder if ESB/Service Bus is a part of every SOA infrastructure or is it something different?

5) Do you have any other suggestions/tips for me to consider as an Web-Services and SOA Evangelist?

6) Does Spring-Integration provide any means for SOA? Can you please direct me to some examples?

рüффп
  • 5,172
  • 34
  • 67
  • 113
rbhojan
  • 83
  • 1
  • 6
  • You might get more help if you narrowed down what you're are curious about into questions that can result in answers, not questions that promote discussion. SO isn't a discussion forum, it focuses on the Q&A format. – Pedantic Dec 17 '13 at 21:53
  • Thanks Pedantic, I would do that! – rbhojan Dec 17 '13 at 22:58
  • I'll give you an upvote, its a wide open topic that can use some discussion but this isn't the proper forum for it. Try programmers.stackexchange.com for better help narrowing down your topics, but I'm afraid a lot of these topics are still too broad for even there. – Pedantic Dec 18 '13 at 05:16
  • Anyway, my takeaway from the whole "SaaS" buzz is this - if you're looking to start up a service that provides SOAP or REST services, authentication/authorization and governance is key. I hate to admit it but some Big Data company (who gets a lot of flak) did it right, but its a pain in the ass to implement. – Pedantic Dec 19 '13 at 06:11

1 Answers1

1

This is a quite broad and subjective question . The key question to ask is what value would an ESB provide that your applications cannot deliver. The answer depends on your use case and you existing technology eco system . For example if you use legacy technologies that doesn't provide web-services ground up, then having an ESB infrastructure will help you quickly "web service enable " .

You might also want to use ESBs to act as a proxy that apply the ACL rules or encryption or security controls . Certain ESB ( Appliances ) provide FIPS-140-2 controls , intrusion detection etc that you may on may not need .

ESB does provide significant governance and operational/ monitoring capabilities out of the box , especially if you are using the web service (SOAP/WS-* ) services .

Scale and Latency is not a function of ESB itself but , it depends on what product and how it is implemented . You could implement a highly available and scalable web service endpoint without an ESB . However there are certain appliances ( Data power , Intel ESG etc ) that provide significant hardware acceleration to certain process ( e.g. XML/XLST etc )

Another aspect of using ESB is to understand who your consumers /providers are . Are you looking at dealing with different protocols with different consumers /providers . Are you required support multiple payload types ( XML , JSON ) . I would also says that its not necessarily to have an ESB to meet these requirements but it might make it little it easier for you to have the business app do only implementation of the service and ESB offer various end points depending on the needs of the consumer .

Most importantly SOA is an Architecture pattern not a single product. There is nothing that says "SOA" means ESB , you could very well design a spring integration or Apache Camel based application that is service oriented , scalable and flexible

So that's some of the advantages of using ESB and here's some links as to why you shouldn't use one

Slideshare PPT

Eric's Blog

Since you getting started on Services , another aspect you might want to make it Restful Vs SOAP based services . There's lot of content on the net , following are some links to get you started .

Hope that helps.

http://www.ibm.com/developerworks/webservices/library/ws-restful/

http://martinfowler.com/articles/richardsonMaturityModel.html

Ren
  • 58
  • 1
  • 6
  • Good way to break it down, but I still think the original question(s) is (are) way too broad to be useful. – Pedantic Dec 19 '13 at 05:56
  • Thank You Ren. This does give me some insight. – rbhojan Dec 21 '13 at 01:03
  • I always used to wonder what is the real benefit of using SOA infrastructures , and channeling the messages through ESB, while we can build our own Orchestrator etc... Based on your comments I could infer that if I have to build my web services from scratch, then there is really not a big advantage of using any ESB framework as against managing your own web-services and using languages like Spring-Integration to write/build custom orchestration. ESB frameworks could provide some ease of implementation if we have some legacy applications which are to be exposed now as web services. – rbhojan Dec 21 '13 at 01:12
  • The main concern which bothers me is while we are beginning our journey of developing multiple web services in our company... which is pretty small as of now... I wonder if we should consider frameworks like Apache ServiceMix, Mule ESB, IBM DataPower, Oracle SOA Suite etc... or if we should start with simple independent web services and later on explore options for using such frameworks to bring all the web services together under one umbrella. I am in a dilemma coz I don't want to over-engineer but at the same time I am afraid if ignoring SOA frameworks right now will cost us too much later!! – rbhojan Dec 21 '13 at 01:18
  • If you are a small company , stay away from large product suites which are designed to solve problems for large enterprise . Those are elephants on their own might . As long as you maintain the standards , SOAP , WS- Security , Restulful etc , you should be able to move to those infrastructures later without significant lift. It's okay to start small and migrate than over-engineering . What you need to make sure is your design is clean such that they allow a seamless migration later . – Ren Jan 02 '14 at 23:32