JBI ? SCA
With all respects to the Gurus of technology I would like to putforward my thoughts around "JBI & SCA". If any of my perceptions are wrong kindly send your valuable comments for my further learning....as you know Learning is a Never ending aspect for everyone.
I prefer to see JBI(Java Business Integration) & SCA(Service Component Architecture) as two complementary entities while building Service Oriented Business Integration. I define Service Oriented Business Integration as "Pragmatic Integration Architectural approach,to develop Collaborative, Standards oriented Business Integration Solutions by leveraging SOA Principles, Applications, Computing Resources & Environments etc"
Some of the industry technology analysts viewed JBI & SCA as competitive to each other, to a certain extent it is & it is not??? Fundamentally it is how you look into the usage. Some of the comments circled around JBI comparing against SCA are
JBI falling out like another Hub-and-Spoke (HaS) environment: Truly not. One has to understand traditional HaS Model of EAI and the latest ESB architecture based on SOA Standards and Level of Abstraction it offers. Some how I feel who ever is comparing Traditional HaS models with Modern ESB is as good as comparing "Ape Man Vs Modern Man". Nothing varied much in appearance (hands, legs, head, heart) But lots of Modernization in behavioral aspects.
Hub-and-Spoke(HaS) systems contains centralized hub that is responsible for connectivity, Message transitioning relating to requests/responses, coordination with spoked-in applications. Spoking to Hub from each application happens thru a Connector.
Bus in the ESB - is a central unit which has abilities to keep Delivery channels to Congregation of Service Containers. Most of the latest ESBs provides distributed services infrastructures for development and deployment of services in any of the containers of the choice. ESBs also offers messaging, routing, and data transformation through XML.
The key difference of traditional Bus based HaS integration systems Vs modern day ESB's are abilitty to support SOA mechanism
- Service Interface Design
- Service Composition / Composite Application Development
- Service Delivery
- Service Access
- Service Control
- Service Governance
- Service Standards
- Service Orchestration / Choreography
- Activity monitoring
- Deployment monitoring
More over mostly an intelligent ESB manages Containers by providing a common place for all service containers to live & perform, making an ESB as a Container of Containers rather than a Congregation point of direct Applications to be managed. Another advantage of ESB all its operational management is truly distributed unless its older look-a-like HaS as Cenrally manageable.
Any environment which provides all these in a well structured distributed environment is definitely a good choice to do Business Integration. With JSR-208 JBI and OpenESB Community all the above said are well taken care proving JBI as an irrefutable environment for Business Integration application development & deployment.
In the same context Service Component Architecture (SCA) initiative brings most of the Architectural principles on how to develop Service Architectures and components. This initiative offers lots of specifications for Service development & implementation. SCA emphasizes the bifurcation of service implementation assembly from the intricacies of Service Runtime Infrastructures. This decoupling of Implementation and Assembly from Runtime environments gives a different perception to develop SOA services - and deployable across many Integration Environments. More over SCA highly encourages to decouple middlewear with Service components business logic development.
But in my view SCA is not meant to replace any of the technologies like EJB, Webservices etc, the model offers a clean way of developing Service Interfaces using your choice of technology, and implementation of each individual component or a service using any of the technologies of our choice depending on the Problem scenario. SCA also puts standards across how services are WIRED with other services. For wide varieties of data integrations SDO (Service Data Objects) offers the technology to show a Unique model of the data to the services business logic.
With all this said - is SCA Not sounding like a Well Defined Architectural Practices guidelines for SOA Development? Yes it is. Given the fact that one follows SCA Standards at a Developer level - still we can leverage capabilities of JBI to a bigger context to deploy,manage, integrate SCA oriented services in Business Service Integration technologies like OpenESB.
- Coming to the OTHER CRY of industry that "JBI is a pure Java community View of Integration world" - So What! it is offering all the ideologies of an integration environment as mentioned above, and it is not enforcing anyone to write their fundamental/elemental business services only in Java. It is specifying a better way to hook the services to a JBI environment like OpenESB by providing SPI's (Service Provider Interfaces) - I don't think anything wrong in this methodology. If you see that JBI is forcing a service vendor or a developer to write their fundamental/elemental services as JBI, the perception is wrong! It is providing a way to integrate into a larger Integration environments. If this is the case I believe SCA & JBI/OpenESB are complementary to each other rather than competitors on any aspect.
- One other issue pointed in general discussions are "JBI is enforcing a J2EE container" to live, like on GlassFish, Sun Application server etc. To a matter of fact every software of this complexity defintiely requires a CORE or a kernel to work- why not a a J2EE container can offer JBI services to the BIG integration challenges. How many are really having issues of hosting a J2EE container as a matter of fact in their big enterprise installation? I may anticipate JBI to run on its own in the future to avoid J2EE dependency if acceptance and adoption of J2EE containers is a challenge for Business Enterprises.
Posted at 02:22PM May 23, 2007 by Sasikanth Tenneti in Sun | Comments[2]
Is That All (SOA = Webservices?)
During my recent SUN ISV meetings I faced one frequent question on WebServices & SOA.... Is Webservices = SOA or SOA = Webservices. My answers is an immediate NO, NO - followed up by non-stop few mins talk on the differences. Everytime I answered this question I have covered many different topics to delineate and contextify (dont laugh - you can't find this word in dictionary :-) ) "SOA & Webservices". I feel putting my ideas around this on my BLOG makes more sense for a wider distro when ever I require, and my answer starts like this ....
The essential feature set of SOA is having a bigger context and bigger requirements than the feature set offered by Webservices. Lets quickly review what are those.
Most of these features can be achieved through distributed component architectures like Webservices, CORBA, COM/DCOM. Certain essentials of SOA like Governance & Standards, Architecture principles, Process & Practice are more to do with People participating in SOA maintenance and also Enterprise business process. Here Governance is a pure form of People's practice on incubating applications within an enterprise practicing SOA. With this said it looks like we can achieve most important features of SOA through Web-computing Distributed Component architectures like (Webservices, CORBA, DCOM), but the wide acceptance to Webservices happened because of its Open-Standards than CORBA, DCOM.
CORBA, DCOM are tightly coupled with the implementation program that is providing the service is directly associated with the program requesting the service. This makes the SOA as a proprietary implementation but not OPEN.
Coming back to the topic whether or not SOA = Webservices. It can't be, as Webservices addresses few challenges to achieve SOA with a careful service composition. Standards based Interoperable Service components composition is very easy and highly valuable with Webservices standards but there is no SILVER BULLET ANSWER from Webservices to address Process orchestration, Process definitions, Service Control, Service Accessibility, Service Composition, Business Activity monitoring and Governance, Event Management etc. Webservices suitability in each and every aspect of SOA is a choice given based on requirement. If there is any other component or tool which fits to the context better than Webservices is definitely adoptable. For example a typical EAI Challenge of "High Volume Data Integration" within an Enterprise off-line process. Given this scenario using an ETL Tool (Extract, Transform, Load tool) than a custom built Webservice is a wise adoption.
Conclusion - Taking all the Enterprise SOA Challenges if we need to put down suitable component architectures, there is a possibility that Webservice component architecture sits on top of all - but definitely not Everywhere. In a N-Tiered architecture SOA systems Elemental business services may or may not exist with Webservices, Once the Composite applications are built on top of Elemental Business services then the possibility of having Webservices in "Composite Tier" is very high for Webservices. Still depending on requirement elemental business services can be composed with EJB, COM, CORBA, etc component architectures.
Posted at 11:28AM Mar 14, 2007 by Sasikanth Tenneti in Sun | Comments[0]
Shaping Future of the Web with "Web 2.0 & SOA"
I am trying to put my thoughts around SOA & Web 2.0 where certain boundaries are not crispy yet, mixing them with decent boundaries requires lot of harnessing on complementary features. While SOA embrassing richer architectural principles emphasising on Interoperability, Federation & Discovery, Governance, Reusability of Services etc - Web 2.0 taking a shape as a de-facto standard to change web-based user experiences. As these two well accepted Concepts in the current IT era, I would like to put on my thoughts around how these two are aligned?
Are they complementing each other on any key features?
Are they addressing any common challenges?
Here is a diagram that can be extended a lot - I tried to capture most minimal things of commanalities and differences.
I feel right usage of Web 2.0 standards and SOA is really matters and makes lifes easy to understand if and only if there is a compelling need to leverage on the comman features that "SoaWeb" can offer. Simply trying to put everything together may or maynot fit 100% well to anyones requirements. But certain definite features of AJAX user experience in SOA based enterprise systems will be of great value as it gives a great face lifting to the current days GUI strategies that are going with enterprise systems.
Posted at 12:26PM Mar 12, 2007 by Sasikanth Tenneti in Sun | Comments[0]
Webservices Orchestration Vs Choreography
Orchestration Vs Choreography
While doing service composition in typical SOA-based applications using Webservices standards - Orchestration & Choreography comes into picture very commonly on most of the tutorials, articles etc. Whats the difference between these two words? in the context of Webservices usage in SOA?
Webservice's Orchestration - Leveraging Webservices open-standards & collaborating different webservices functionality to compose an "Executable Business Process is called as Webservices Orchestration". It is easy to define Service Orchestration also in the same lines without using the Web-open-standards. To tailor made the flow of webservices and to compose a service we need to tie-in all the different webserivces at a Message Level, meaning that at a raw exposed method level by defining the order of execution of the business logic exposed methods. Here Orchestration deals primarily with
* Message Level business logic exection
* Order of business logic execution - that generally resides at exposed business methods of the webserivce participating in the whole orchestration of the service.
These webservices may or may not run in the same localized environment relating to one enterprise, in some cases these services may be running outside the enterprise network in some other enterprise business / Organization level.
Coming to some of the open standards -
WSDL - of a webservice describes specific operations allowed on a webserivce component,
BPEL4WS(Business Process Execution Language for WebServices) is an XML based language which describes grammer, process flow of webserivces. BPEL works on top of WSDL on sequencing the operations defined in WSDL and facilitates to define a process flow. Once the Business Process is defined it can be exposed as a webservice again using WSDL. Also BPEL defines exception handling mechanism of operations, transactions on operations. Overall BPEL standard helps to define the webserivces message flow in the Business Process Orchestration.
Webservices Choreography - this typically deals with messaging between various stakeholders of a business process viz., Customers, Suppliers, Retailers, Partners etc. not like Orchstration responsibilities which mainly focuses on Webservices level message flow. Like BPEL(for Orchestration) works on top of WSDL, Choreography standards like WSCI(Webservices Choreography Interface) also works on WSDL but mainly focuses on the public interactions. WSCI also supports Transactions and Exception handling like BPEL. WSCI focuses more on public interaction with the webservices end-point (which is offering a service), and if the end-point uses more and other webservices interaction using private interfaces then BPEL can be used to define that.
Conclusion - The business level collaboration can be easily found in Choreography / WSCI. The glitch here is BPEL4WS can also be used for external public interaction across all stakeholders, but BPEL4WS was never gained that promotion in the context. It is upto product vendors how they would like to shape their products based on these existing Open-Standards.
Posted at 11:51AM Mar 09, 2007 by Sasikanth Tenneti in Sun | Comments[0]
Will SOA Die?
Will SOA Die
Its difficult to predict "Will or When is SOA going to die" instead, what makes SOA to die is a better way to arrive at When/How... Year 2005 is considered to be a year of SOA getting into limelight, almost entire industry realized to take this as a momentum. Depending on Enterprise applications size, complexity, number of applications, number of integration challenges etc are to be considered to determine SOA effort estimation. To provide complete SOA to an enterprise it may take any number of man months/years. Buzz in the industry tells that bigger System Integrators even signed for a 10 year contract with enterprises to unify their applications under the umbrella of SOA.
In the midst of the architectural concept acceptance to the industry, some product companies started building SOA Development tools mainly to ease Integration challenges( like - software gateways, webservices build tools, ESB etc) and Development Challenges(like - easy way of writing Webservices Description languages, Business Process languages BPEL, BPMN etc). These tools are assisting Integration developers to achieve SOA results in the most fastest way by reducing the custom programming time and cost, de-linking developer from certain low level intricacies of programming to the development platforms. Considering the strategic acceptance, maturity of industry towards SOA I still feel this concept is just evolved out of Incubation Phase. Enterprises are really doing it now rather than doing Proof Of Concepts which are generally helpful to make a decision on incubating a new methodology or new software.
Definitely during the current phase of implementation of SOA based systems enterprise IT teams will start realizing the pain points of doing SOA, and much better way of doing SOA, or even a different way of doing SOA. One such methodology which is gaining momentum is EDA - Event Driven Architecture. Is it next generation SOA or SOA Version 2.0? Probably Yes or no. But during this evolution phase definitely improvement areas will be much more visible based on the missing flavours in SOA - that lays out a foundation for New Generation of architectures like EDA etc. This transformation from SOA to some other architectural practice WILL CARRY ALL THE FLAVOURS OF SOA + Enhancements on architectural/development practices - with this I feel SOA will never die, it will be carried with greater momentum, better way of carrying the things. In such a world of IT scenario SOA still be alive in a larger context of doing software architecture..... Long live SOA.
Posted at 11:29AM Mar 08, 2007 by Sasikanth Tenneti in Sun | Comments[0]
SOA & Java Composite Application Product Suite
Posted at 03:56PM Dec 01, 2006 by Sasikanth Tenneti in Sun | Comments[0]