Building an object-oriented application on top of CMIS can feel just about as low level as using raw SQL. For SQL databases, we have OR-Mappers such as hibernate or libraries such as ibatis in the java world to provide us with basic CRUD functionality for writing an application.
Of course there is no spec-based API analogous to JDBC (on which the higher level relational "tools" rely) for CMIS, but I guess that does not make a significant difference addressing the issue.
Are there any efforts making the life of CMIS-App developers a little more convenient ?
Have a look at http://chemistry.apache.org/java/opencmis.html. It is mainly developed for Java but is available (at different "stability") for python, .net and phph
We've been having a discussion at work over how widely used SOA is. We've been building our businesses processes using SOA for a few months now with varying degrees of success and the question came up about how widely used this architecture is. My manager believes that "most" of the big companies are using SOA and it is gaining steam among the industry, is cutting edge technology and everybody will doing it shortly. I argued that it seemed to be the new buzzword about 2-3 years ago and was never widely adopted.
Does anybody feel strongly one way or another?
Thanks.
SOA is an easy, standard way to write web services that other middleware (and user-space code) can use. If you need to integrate existing code/services with web clients or other middleware clients, its a good thing to consider.
You didn't mention much about what you're trying to accomplish or what technologies you need to integrate, but I have written Oracle SOA web services that are consumed by Android in the mobile sphere, Spring in the web sphere, and other Oracle SOA clients in the enterprise sphere.
All depends on what you're looking to do, but SOA is more of a concept - and a borderline standard for integration architecture, that presupposes any particular implementation.
As a modern large company, is one ERP system better than hundreds of highly specialized applications which are service oriented? To provide a little bit of background, we are providing consulting for a client who wants to invest their resources in a monolithic ERP system which will manage everything! What are the pro's and con's of this approach?
As an application developer, I tend to believe that specialized well written and managed software packages tied together by a service architecture would out perform a monolithic approach.
What do you think?
As an application developer, I tend to
believe that specialized well written
and managed software packages tied
together by a service architecture
would out perform a monolithic
approach.
Maybe, but getting support for one system from one party is easier than getting support from multiple parties and making sure that integration works and keeps on working.
I think a more important question is whether to pick a general ERP or a custom fitted one. Whether the architecture is service oriented or monolithic is maybe is related, but also general ERP systems can be service oriented.
This almost feels like a traditional question on buy vs. build. I will try to lay out
some importan points.
If you clients has deep pockets only then can they viably maintain the high total
cost of ownership and complexity associated with developing and
maintaining custom-designed applications.
Off-the-shelf ERP solutions integrate the best business practices from a variety of
industries and incorporate these best business practices into your
client's operations which ultimately translates into bottom-line improvements.
Custom-designed applications provide the desired degree of functionality,
but their size and complexity require lengthy design, development, and
implementation efforts.
A good example that I can think of is Microsoft. Microsoft spent 10 months and $25 million installing SAP R/3 to replace a
tangle of 33 financial-tracking systems in 26 subsidiaries. As a result of the
implementation, Microsoft estimates annual savings at $18 million,
leading Bill Gates to call SAP "an incredible success story."
Hope this helps you think more broadly from all angles.
Can somebody provide real world examples of software products or applications (commercial or open source) that have SOA in them?
Like for example some X company claiming that the latest released version of their software product is now SOA compatible.
SOA is not a specification that a software product could be claimed to be SOA compatible. Read more on what SOA is at http://en.wikipedia.org/wiki/Service-oriented_architecture
SOA is basically an architecture/implementation technique which aims towards loose-coupling of the presentation layer with the data layer. Thus, multiple services/modules/applications could access the same data and use it as per their need. This loose-coupling can lead to more of distributed programming. The day you see that a particular service is more in demand, you could add nodes to your cluster for the particular service.
Examples per se would be applications that were build with SOA architecture. Liferay (an open source Java CMS) is a service-based application. All application that expose some sort of an API (see programmableweb.com) can be termed as SOA-enabled where in you pull data and consume it the way you want.
But yes, for sure, SOA is not a specification.
Service Oriented Architecture seems to be more and more of a hot quote these days, but after asking around the office I have found that I seem to get many different definitions for it. How would you guys define SOA? What would you consider the official definition?
As Martin Fowler says, it means different things to different people. His article on the topic is pretty good although it isn't quite a definition.
http://martinfowler.com/bliki/ServiceOrientedAmbiguity.html
It may explain, the difficulty coming up with a concrete definition.
Wikipedia: "A SOA is a software architecture that uses loosely coupled software services to support the requirements of business processes and software users. Resources on a network in an SOA enviroment are made available as independent services that can be accessed without knowledge of their underlying platform implementation."
SOA is not that new, but it has potential to achieve some amazing things. But the organization has to be ready for it: the business has to think in processes and that's the big problem
I'd go with:
Defining a series of stateless, client
agnostic business operations created
to be leveraged in multiple
applications.
An SOA design includes components (i.e., services) that can be used by code regardless of implementation (i.e., any OS or langauge). A single instance of a service may also be used by multiple applications, whereas, e.g., a DLL would have to be duplicated for each app and require the same implementation technology as the linking application.
Services in an SOA design are usually implemented as interoperable web services.
There isn't an official definition as Ryan mentioned eariler. However, I find Thomas Erl's view of the whole service-orientation quite well-structured and relevant. Here is the definition of SOA from his SOA Glossary (more):
Service-oriented architecture represents an architectural model that aims to enhance the agility and cost-effectiveness of an enterprise while reducing the overall burden of IT on an organization.
Thomas Erl is the author of many SOA titles most of them receiving endorsement from SOA vendors including IBM, Oracle, and Microsoft. The nice thing about his books is that they are as SOA vendor independent as possible. It means you learn more about service-orientation itself and less about some vendor's middleware that supports SOA.
I agree with all of the people that point you to Fowler on this. Basically it runs like this: service oriented architecture got a reputation as being good, so anything that people want to be associated with good they call SOA. In reality it has a lot of downsides and can create a Service Oriented Gridlock or Dependency Oriented Architecture.
Here's my go at a definition:
Service Oriented Architecture is a systems integration and code reuse approach where applications are dependent on connecting to services provided by other running applications across the network. This is distinct from component architectures, where software components are shared statically between applications in the form of libraries or SDKs, for example.
A clarification here - "Service Oriented Architecture is a systems integration and code reuse approach where applications are dependent on connecting to services provided by other running applications across the network."
I have a scenario where two j2ee applications have been integrated using event driven messaging. Here the above phrases of systems integration and connecting to services provided by other running applications across the network hold good. Can i call this SOA ?
The following principles would hold good here
1) statelessness
2) message oriented - loosely coupled infact de-coupled
3) extensible.
However, the following do not apply
1) platform independence - neither of the applications being integrated has been designed to work in a different platform.
2) The applications are plain j2ee applications which have not been designed with all soa concepts.
I attempted to define SOA in one of my blog posts. Here's an excerpt...
For years it's been standard practice to separate functionality into functions, classes, and modules. The idea has always been that these smaller, highly specialized components are easier to share and maintain than monolithic blocks of code.
Functionally, SOA is not much different. The goals are the same - reusability and easy maintenance. The biggest difference - in the case of a web service SOA - is that the shared library included in your application is replaced with an HTTP call.
Here's a definition for you:
SOA - Software Over Architected. The inclusion of pointless, over-bloated, functional interface framework called an architecture in a pretty web site with a 3d graphic folder flying from one side to the other where "dir /s > a.txt | ftp -s:upload.ftp" did the job.
Software components are not bricks, cannot be generalised by common functional patterns and architecture emerges in the enterprise from good practice, not good design. Software isn't architected, it's engineered.
SCRUM ON!