Prizes & Awards
My Profile
Active Members
TodayLast 7 Days
more...
|
Resources » Articles » WCF/Webservices »
Service Oriented Architecture
|
This article is a brief introduction to Service Oriented Architecture. Using this new architecture we can create distributed applications, separating each tier with walls of abstraction, maintaining each tier independently. This architecture enables us to expose the business functionality as a service using universal standards.
Definition: A service-oriented architecture is essentially a collection of services. These services communicate with each other. The communication can involve either simple data passing or it could involve two or more services coordinating some activity. Some means of connecting services to each other is needed.
Service-oriented architectures are not a new thing. The first service-oriented architecture for many people in the past was with the use DCOM or Object Request Brokers (ORBs) based on the CORBA specification or J2EE (details furnished later).
Why SOA? :
SOA is about managing information. Unlocking the true potential of the information that an organization manages. Business integration (i.e., the task of tying many information systems together to support a business process) is the technique used to achieve this.
SOA has come up with a simple idea of solving business integration problems. The entire application/solution is wrapped in a well-defined interface and is converted into a “service”. There exists now an abstraction, hiding all the intricate details of the application. The client now does not have to know what language, operating system or the database the application uses. The client (an application or another service using this service) only has to know the interface of our service (description of our service).
If all applications are accessible on a common network (like the internet or an intranet), it is possible to plug all these service into a single system. As soon as I require a certain service, I just have to write that service and plug it into the system. No matter what platform, operating system, or language the service is written in, they all can talk to each other.
Previous implementations of service-oriented architecture were done using technologies like DOM, CORBA and J2EE as mentioned above. Now the question arises why did we come down to web services when there were technologies available that implemented the service-oriented architecture. Surely there were some things that those technologies got right while others that went wrong.
DCOM:
Microsoft® Distributed COM (DCOM) extends the Component Object Model (COM) to support communication among objects on different computers—on a LAN, a WAN, or even the Internet. With DCOM, your application can be distributed at locations that make the most sense to your xcustomer and to the application.
Because DCOM is a seamless evolution of COM, the world's leading component technology, you can take advantage of your existing investment in COM-based applications, components, tools, and knowledge to move into the world of standards-based distributed computing. As you do so, DCOM handles low-level details of network protocols so you can focus on your real business: providing great solutions to your customers.
DCOM is an extension for COM. COM is basically defines a standard regarding how components and their clients interact. This interaction is a connection between the client and the component without the need of any intermediary system component. The client calls on methods in the component without any overhead whatsoever.
But COM only provides for communication between components within the same process. But in today’s software development environment applications and processes are shielded from one another. Applications exist in separate processes. A client that needs to call on a component residing in a separate process cannot call on it directly. It has to use some sort of inter process communication provided by the operating system. COM provides for this communication transparently. It intercepts calls from a client and forwards them to the component in another process.
When client and component reside on different machines, DCOM simply replaces the local interprocess communication with a network protocol. Neither the client nor the component is aware that the wire that connects them has just become a little longer.
CORBA:
CORBA is the acronym for Common Object Request Broker Architecture, OMG's open, vendor-independent architecture and infrastructure that computer applications use to work together over networks. Using the standard protocol IIOP, a CORBA-based program from any vendor, on almost any computer, operating system, programming language, and network, can interoperate with a CORBA-based program from the same or another vendor, on almost any other computer, operating system, programming language, and network.
These were the 2 technologies that were previously used to implement service-oriented architecture. Taking a service oriented approach, basically, means taking a look at the problem from the user’s point of view and breaking the solution into discrete “chunks” of functionality/services that each serve specific purposes and that can be assembled together to create true value for the user. A key characteristic of the service-oriented model is the loose coupling between the services, which allows the services to be recombined and repackaged into new kinds of complex solutions.
J2EE:
The Java 2 Platform, Enterprise Edition (J2EE) technology provides a component-based approach to the design, development, assembly, and deployment of enterprise applications. The J2EE platform uses a multi-tiered distributed application model. This means application logic is divided into components according to function, and the various application components that make up a J2EE application are installed on different machines depending on which tier in the multi-tiered J2EE environment the application component belongs.
J2EE applications are made up of components. A J2EE component is a self-contained functional software unit that is assembled into a J2EE application with its related classes and files and communicates with other components. The J2EE specification defines the following J2EE components:
? Application clients and applets are client components.
? Java Servlet and Java Server Pages (JSP) technology components are web components.
? Enterprise JavaBeans (EJB) components (enterprise beans) are business components.
J2EE components are written in the Java programming language and compiled in the same way as any Java programming language program. The difference when you work with the J2EE platform, is J2EE components are assembled into a J2EE application, verified that they are well formed and in compliance with the J2EE specification, and deployed to production where they are run and managed by the J2EE server.
Coming to discuss what went wrong with these technologies, these are the general areas.
? The interface language:
If the service-oriented architecture has to take off, it has to have a wrapper language that is universally accepted. In Microsoft DCOM there was Microsoft Interface Definition language. In CORBA there was CORBA Interface Definition Language and in J2EE there is java. All these languages were popular but none was universally accepted. There were groups and cliques of enthusiasts that wouldn’t go for anything but what they followed.
Web services use a universally accepted interface language. Based on the now universally accepted XML Web Service Definition Language (WSDL) has the backing of every single vendor on the planet. The fact that Microsoft and IBM came together to create this standard is of enormous importance.
? The network infrastructure:
All the applications have to be plugged into a network infrastructure that is ubiquitous. All the technologies came up with their own proprietary solutions but they were not by any means a universal solution. There is only one network infrastructure that meets these requirements and that is the Internet (used by web services).
When you consider the universal acceptance of protocols such as HTTP and SMTP, there are some immediate technical and economic observations that have to be made. Firstly, there is nowhere on the planet that cannot be reached by HTTP or SMTP. Because of this ubiquity, the efforts made to make these protocols secure, reliable, manageable, and highly available benefit from enormous and unparalleled economies of scale. There is no economically feasible way to make any other set of network protocols as universally dependable as HTTP and SMTP. Therefore, there is no other set of network protocols that can possibly form the basis for a universal integration bus.
? Evolving interfaces
Services have to be flexible to change. In software development, volatility is indispensable. Software has to be open to evolution because requirements evolve over time. They must have the capacity to respond to different message types. J2EE and CORBA required their interfaces to be very rigid. DCOM supported some interfaces changes but in a very complicated manner which was not at all acceptable. This inability to evolve interfaces, have made service-oriented architecture hard to deploy and manage.
Few people have really delved into one of the more subtle aspects of Web Services: how Web Services radically change the notion of what an interface is and therefore make it more open to flexible use.
We call interfaces as contracts. But we don’t literally mean it. But as far as web services are concerned, a web service interface is a document. It is literally a contract written in XML (which happens to be the most flexible and popular format today) complete with a schema definition.
Furthermore, in Web Services the data that is exchanged can be any random XML document, using XSLT (the XML transformation technology) to transform it on the fly into the desired format so that it can be consumed correctly. In a Web Service-oriented architecture, we are not confined to simple data types. If I want to exchange Microsoft Word documents, pictures, insurance claims, e-mails, or any other type of information, the set of technologies in Web Services make it trivial to do so. In the previous technologies, the data accepted by the interfaces was one very rigid format. Using Web Service-oriented architecture, I can build interfaces to accept a rich and varied set of input documents.
? Distinct separate interfacing and programming models
All the technologies involve their own programming models. Usually when creating interfaces, you have to create an interface, and then provide its implementation. This involves learning. Learning a technology, learning a programming model, learning languages, etc. shifting back and forth from one language or platform to another again is a big issue. There is not one universal programming model, which makes service-oriented architecture complex.
Finally, a Web Service-oriented architecture succeeds because it has nothing whatsoever to say about the way in which the interface gets implemented. Web Services can as easily provide a wrapper around a mainframe CICS application as they can provide a wrapper around a Java class. Web Services provide only an interface layer and the information bus. That's all! In most Web Services products supporting integration there are no APIs to be learned.
This radically simplifies the whole task of building and deploying a Web Service-oriented architecture. It means that the pool of talent from which to draw the staff needed to implement a Web Service-based integration is several orders of magnitude larger than the talent pool of those who can program to DCOM, CORBA, or J2EE.
Now that we have talked so much about the web services. It seems that these are the best things that could happen to the software development arena. Well even service-oriented architecture is not without objects. There always will be a group of people who would have objections with no matter how good things you give them. And it is on these people that the growth and development of every field depends on. These people make us thrive for something even better.
The objections are as follows:
? Not Mature: They say that the underlying set of standards in and around web services (SOAP, WSDL and UDDI) are not mature enough and don’t offer sufficient guarantees of interoperability. It is true that J2EE and CORBA have taken years offering limited amount of interoperability. The two main reasons for this are, firstly they both rely on binary wire protocols, which take years to perfect. And secondly, because they use their own proprietary protocol that are not firewall friendly. So it is nearly impossible to make a J2EE or a CORBA endpoint available over the Internet.
Web services are based on the ASCII wire protocol running over universal protocols like HTTP and FTP. ASCII protocols have time again proved how interoperable they are.
And as far as testing is concerned, it is entirely transparent. Every vendor makes a web service endpoint available over the Internet and anyone is free to test it.
? Unreliable: Another object that is very commonly raised is of reliability. They say that technologies like J2EE, DCOM and CORBA are specifically engineered to provide the best of reliability, scalability and dependability.
This could be true. But the proprietary protocols that these technologies use are used so occasionally that it would be very difficult to say anything for certain. But what we can say for certain is that the HTTP protocol has proved to be the most reliable and scalable protocol on the biggest network in the world.
? Slow: Performance is another issue that comes in the objections against web services. Here we must agree that yes web services are a bit slower than alternatives. This is a relative price that we pay for a technology that is vastly easier to use and much more interoperable than its counterparts.
Conclusion
Service oriented architecture works as a common platform for different types of applications working on different platforms, created using disparate technologies. And the beauty is that the developer does not need to know the internal details of the disparate systems like object activation, type systems supported, protocols and standards used, etc. Service oriented architecture inspires loosely coupled distributed systems which enhance adaptability to changing environment. It enhances the flexibility in the design of the system.
|
Responses
|
| Author: N.T.Gopalakrishnan 25 Feb 2004 | Member Level: Gold Points : 0 | This was a very good article. Thanks for that. You could also download a PDF at http://www.thearchitectjournal.com/Journal/issue1/article1.html which tells you about SOA in detail.
|
|