As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I've been given the task of laying the groundwork of a SOA for my client. The goal is to open up various processes in an end-client independent way and also to make data available offline e.g. for reps visiting customers.
I do have extensive experience with J2EE (Websphere) and web services but I would appreciate advice on how to build up such an SOA.
Where are the pitfalls? What about security? How finely granulated should services be? etc.
Links to tutorials and book recommendations would also be useful.
Thanks!
Pitfalls
Versioning/backwards compatibility: it gets really hard to change a contract once you have loads of clients. I have seen many sites version the APIs by introducing the version in the URL
Granularity
Each service should be reasonly self-contained (don't expect people to do 3 calls before they get what they need)
Platform Independence
Try to give more than one way of accessing your APIs (WS, JSON, REST...)
People can't agree on what SOA actually means.
http://martinfowler.com/bliki/ServiceOrientedAmbiguity.html
(although consensus may have grown since that was written)
I suggest quizzing your client to find out exactly what they mean - if anything. Then give them something that actually provides business value, while ticking any SOA boxes that might coincide with that effort.
Call me a SOA-skeptic. Fowler's lament still seems right on.
I would focus on the more general problem: your client has 2 or more applications that have to collaborate together. Look at old school integration patterns.
(source: amazon.com)
Found this IBM Redbook (#sg246303) which is quite a good introduction to the basics of SOA.
As Alan said, I'd start reading the Enterprise Integration Patterns book. There are a number of ways to implement them either using a messaging system directly such as JMS or using open source projects like Apache Camel, for example see the pattern catalogue.
I'd also look at understanding how to build good RESTful services using JAX-RS with Jersey as a simple way to expose resources for your systems to anyone on the web from any language/platform easily without falling into the SOAP/WS-* deathstar :)
Get an ESB (enterprise service bus): Mulesource is a good choice (Opensource, Mature, yet bleeding edge) . Once you understand it, you will understand SOA.
The goal is to open up various
processes in an end-client independent
way and also to make data available
offline e.g. for reps visiting
customers.
The second half of that isn't really an SOA topic, it's more of a replication to mobile devices problem. I would stay far, far away from trying implement a buzzword and focus on the problems that you are stating. Web services are good way to open up process to client independent ways.
So far the best book I found is SOA Compass also available on Amazon
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I was recently working on a Web Service Project and realized my choice of architecture was extremely inefficient.
I wrote this in a very procedural manner with a hint of OOP and standard Exception Handling using Python. Basically, it would procedurally step through the data, validate existence of expected data, validate the data against a regular expression, validate some data against a database, perform some specific logic, check for errors, and then finally return a response. It might be helpful to mention that all data was exchanged using JSON.
I tried to go back through the code, find any duplicated exceptions, and push their handling to the top of the logic chain. This was not as easy to do as I had hoped and actually cost more time. It also made my code more prone to bugs by being less Unit Testable and harder to read.
I've noticed this paradigm of procedural code for handling User Data is very easy to fall in to with Web Development. For example, while handling a Form in PHP one may run a consecutive series of isset() and !empty() methods on the data. My problem with this coding style is that I feel like I'm spending an enormous amount of time coding for Error Events and it's difficult to generalize and re-use code for this particular purpose.
Various frameworks offer great ways around this through the use of Form Classes (e.g. Django). However, I have noticed that while you save time by reducing the duplication of Validation Logic, you will still need to "build" a Form for each expected input. When dealing with Software as a Service, there can be potentially hundreds of API Methods that you must code for. OOP offers a benefit here but there are times where a client may set an odd requirement which removes any efficiency gained.
Web Applications can benefit greatly from following paradigms/architectures such as MVC. In my personal experience, MVC (and the frameworks which use its principles) are not well tailored to this type of problem. I've considered the use of Functional Languages but have yet to give them a try.
Are there any particular languages, architectures/paradigms, conventions, or even example frameworks that are well suited for the development of custom SASS or Web Service Projects?
As someone who does a lot of this work, I would say that part of your problem with OOP and PHP is caused because initially PHP was not an OOP language. OOP was added to the language later on. So when you look at code examples they often can have a procedural feel.
In recent years I've been most happy with either Spring (Java) or WCF (C#). Both these languages are strongly typed OO languages. From a conceptual standpoint this leads to a paradigm that works well for my projects. Here's the overview:
Endpoints (Either REST or WSDL) -- similar to view in MVC
Services -- These feed the endpoints and coordinate DAOs as needed. Organize these around your business logic
Data Access Objects -- convert data into native objects and vice versa. Organize these around your data sources.
Model / API -- Native Objects to support application and automatically provide documentation for your service.
Hope that helps
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
I already know that ember.js is a more heavy weight approach in contrast to backbone.js. I read a lot of articles about both.
I am asking myself, which framework works easier as frontend for a rails rest backend. For backbone.js I saw different approaches to call a rest backend. For ember it seems that I have to include some more libraries like 'data' or 'resources'. Why are there two libraries for this?
So whats the better choice? There arent a lot of examples to connect the frontend with the backend too. Whats a good working example for a backend rest call to this:
URI: ../restapi/topics
GET
auth credentials: admin/secrect
format: json
Contrary to popular opinion Ember.js isn't a 'more heavy weight approach' to Backbone.js. They're different kinds of tools that target totally different end products. Ember's sweet spot is applications where the user will keep the application open for long periods of time, perhaps all day, and interactions with the application's views or underlying data trigger deep changes in the view hierarchy. Ember is larger than Backbone, but thanks to Expires, Cache-Control this only matters on the the first load. After two days of daily use that extra 30k will be overshadowed by data transfers, sooner if your content involves images.
Backbone is ideal for applications with a small number of states where the view hierarchy remains relatively flat and where the user tends to access the app infrequently or for shorter periods of time. Backbone's code gets to remain short and sweet because it makes the assumption that the data backing the DOM will get thrown away and both items will be memory collected: https://github.com/documentcloud/backbone/issues/231#issuecomment-4452400 Backbone's smaller size also makes it better suited to brief interactions.
The apps people write in both frameworks reflect these uses: Ember.js apps include Square's web dashboard, Zendesk (at least the agent/ticketing interface), and Groupon's scheduler: all applications a user might spend all day working in.
Backbone apps focus more on brief or casual interactions, that are often just small sections of a larger static page: airbnb, Khan Academy, Foursquare's map and lists.
You can use Backbone to make the kinds of applications that Ember targets (e.g. Rdio) by a)
increasing the amount of application code you're responsible for to avoid problems like memory leaks or zombie events (I don't personally recommend this approach) or b) by adding 3rd party libraries like backbone.marionette or Coccyx – there are many of these libraries that all try to provide similar overlapping functionality and you'll probably end up assembling your own custom framework that is bigger and requires more glue code than if you'd just used Ember.
Ultimately the question of "which to use" has two answers.
First, "Which should I use, generally, in my career": Both, just like you'll end up learning any tools specific to work you'll want to do in the future. You'd never ask "Backbone or D3?"; "Backbone or Ember" is an equally silly question.
Second, "Which should I use, specifically, on my next project": Depends on the project. Both will communicate with a Rails server with equal ease. If your next project involves a mix of pages generated by the server with so-called "islands of richness" provided by JavaScript use Backbone. If your next project pushes all the interaction into the browser environment, use Ember.
To give a brief, simplified answer: for a RESTful backend, at the moment, you should use Backbone.
To give a more complex answer: It really depends on what you're doing. As others have said, Ember is designed for different things, and will appeal to a different set of people. My short answer is based on your inclusion of the RESTful requirement.
At the moment, Ember-Data (which seems to be the default persistence mechanism within Ember) is far from production ready. What this means is that it has quite a few bugs and, crucially, doesn't support nested URIs (/posts/2/comments/4556 for example). If REST is your requirement, then you'll have to work around this for the time being if you choose Ember (i.e. you'll either have to hack it in, wait, implement something like Ember-Data from scratch yourself, or use not-very-RESTful URIs). Ember-Data is not strictly part of Ember, so this is entirely possible.
The main differences between the two, aside from size, are basically:
Ember tries to do as much as possible for you, so that you don't have to write as much code. It is very hierarchical and, if your app is also very hierarchical, will likely be a good fit. Because it does so much for you, it can be difficult to figure out where bugs are coming from and to reason why unexpected behaviour is happening (there is a lot of "magic"). If you have an app that fits naturally into the type of app that Ember expects you to be building though, this likely won't be a problem.
Backbone tries to do as little as possible for you so that you can reason about what is going on and build an architecture that fits your app (rather than building an app that fits the architecture of the framework you're using). It's a lot easier to get started with but, unless you're careful, you can end up with a mess very quickly. It doesn't do stuff like computed properties, auto-unbinding events, etc and leaves them up to you, so you will need to implement a lot of stuff yourself (or at least pick libraries that do that for you), although that is rather the whole point.
Update: It appears that, as of recently, Ember does now support nested URIs, so I suppose the question comes down to how much magic you like and whether Ember is a good fit, architecturally, for your app.
I think that your question will soon be blocked :) There are a few contentions between the two frameworks.
Basically Backbone does not do a lot of things, and that's why I love it : you will have to code a lot, but you will code at the right place. Ember does a lot of things, so you'd better watch what it is doing.
Server discussion is one of the few things that Backbone does, and it does a great job with it. So I would start with Backbone and then give a try to Ember if you are not totally satisfied.
You can also listen to this podcast where Jeremy Ashkenas, creator of Backbone, and Yehuda Katz, member of Ember, have a nice discussion
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
We are currently working on an open source project for OWASP, creating a C++ API of enterprise security controls.
The Enterprise Security API (ESAPI) has already been defined for Java EE. We are well aware that requirements of security controls for the C++ language may vary to some degree.
Undoubtedly, some of the largest security concerns stem from memory management, which we are not providing a solution for at this time. So far, we are focusing on several items taken from the ESAPI 2.0 for Java specification. However, there are some questions we have specific to some of these security sections. Mainly, the Java ESAPI has a heavy slant towards web applications, which we know is not the norm for C++. Therefore, we are looking for other areas where common security controls might help the C++ community. It would be useful to know what types of security issues commonly face C++ developers.
We are trying to identify how hackers attack and break your code so we can help provide the appropriate security controls to prevent it.
To aggregate feedback on this project we have created a Google survey; however, please feel free to leave your feedback here as well.
https://docs.google.com/spreadsheet/viewform?formkey=dE5feWtjYlBNU05lV1FxTGNLVExIMVE6MQ
Proposed Security Controls (taken from ESAPI 2.0 for Java):
Authentication - Methods for generating and handling corroborating account credentials and session identifiers.
User - Represents an application user or user account.
Access Control - Methods that can be used in a wide variety of applications to enforce access control.
Validation - Methods for canonicalizing and validating untrusted input.
Encoding - Decoding input and encoding output so that it will be safe for a variety of interpreters.
Execution - Used to run an OS command with reduced security risk.
Encryption - Common encryption, cryptographic random numbers and strings, and hashing operations, and signatures. The cryptographic functionality will be built upon Wei Dai's Crypto++ library for C++. However, our intent is to provide crypto functionality that is simple enough for the average developer to use without any specific knowledge of cryptography apart from some basic terminology.
Logging - Methods designed that can be used to log security events.
Would you consider using this API?
Would this provide a benefit to your development / business?
Any Recommendations?
Any additional information you can provide on this project is useful to us. If there are specific things that would be useful to include that are missing from the above list, or general recommendations you may have, that would be great. Are there things on the above list that you recommend that we leave out because there would be absolutely no way you would use it? If so, then also tell us about those things too.
Thank you for giving this your attention. We hope that creating an ESAPI for C++ will make it easier for developers to write more secure applications.
https://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API
http://code.google.com/p/owasp-esapi-cplusplus/
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I am almost 100% locked in to Django for the projects I have been planning.
The final "myth" I'd like to "dispel" is that Django is "mediocre" at
conveying business-logic.
Direct quote by Peter Shangov:
Whatever your choice of framework your real-life needs will very
quickly outgrow the functionality available in the ecommerce modules
that you started with, and you will end up needing to make non-trivial
changes to them or even rewriting from scratch sooner rather than
later. This is because open source has always been exceptional at
building infrastructure tools (think web servers, templating
languages, databases, cacheing, etc.), but relatively mediocre at
implementing business logic. So what I'd be looking for if I were you
is the library that I'd be happiest to hack on rather than the one
that looks most mature.
"Products" which I am putting Django (with satchmo) up against:
Ruby on Rails (with spree) [Ruby]
Catalyst [Perl]
JadaSite [Java]
KonaKart [Java]
Shopizer [Java]
Could you please alleviate (or confirm) my concerns regarding the
aforementioned quote about Django?
The short answer - of course its bad, because its not a business process management software; it is a framework for web development and getting things done.
The long answer - you need to clarify what you mean by business logic (and "conveying" it). Are you talking about process mapping, workflow management or the execution of the process itself?
I do not see how the other projects you listed "convey" business logic - because they are not business process diagramming or testing or validation packages. They are simply frameworks to do some work. Once the process has been defined and validated (using some external tools), you can then execute that process in your code.
In terms of online shopping - the business "process" as far as the store front is concerned is quite standard and you can easily map it to any of the packages you have listed. You did not mention what kind of store you'll be running or what your fulfillment or delivery processes are, so cannot give you a detailed response if satchmo has those components built-in or would you have to write them from scratch.
The only possible negative when it comes to django is that it doesn't have a mature workflow engine (the two main projects GoFlow and django-workflows are stalled), but this is hardly a criticism against django since it is not a generic web framework. It is designed for a specific application for which a complex multi state workflow engine is not a primary need.
Finally, as far as the quote is concerned - without knowing the context - I can only say that one of the most popular business process mapping software is actually the open source JBoss BPM engine.
I don't doubt that closed-source/proprietary people are great at building infrastructure tools and frameworks too. What they don't do is release them, or let people play with them. They build on them themselves, making money by sticking "business logic" specific to the businesses who give them the money for it.
If you go for a proprietary solution there will doubtless also be some non-trivial changes required, and you'll pay through the nose to the one company that provided you with the (not quite) solution. "Oh, another $4000 to add an extra class of fields to the database? Hmmm. Oh I guess we've already paid you $100,000 and your software is closed source so we can't subcontract it to a tendering process... Here you go..."
Open Source is better at implementing business logic because, when it comes down to it, its people that implement business logic, not frameworks, and open source means more people can work with it.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
1.
I need to build a "Web Service Server (Simulator)" which generates the xml files and also sends async calls to the client for notification. At this point, I am writing a code to generate dummy XML files which will be used for testing (FileGeneratorClass-- builder)?
2.
Also, can I implement this in a way that I do not have to write a complete code from scratch to simulate another web service server and another file format ? - what pattern can I leverage there ?
3.
The objects/classes are generated from a Schema file (for xml File) and WSDLs ( for web service ), how can I make my code immune to changes to these files (newer versions) ? - which design pattern ??
(Please let me know if information I provided is too much or too less, also if you need me to edit)
Thank you very much.
Disclaimer: I am a complete newbie and using patterns for this small project might be overkill yet I want to do it so that I learn/understand it. Which, I think, will give me confidence and clarity when I need to do that in a more complex project.
Patterns don't do anything. You are asking if you should use prepositional phrases when you are planning to write a mystery novel. You don't start a design saying what patterns do I need. Patterns emerge from the design process. You say my program will need x and y, that's similar to the such-and-such pattern, I should see if that pattern fits. If it does, use it. If it doesn't fit, don't force it to fit.
You are treating patterns like classes. Don't do that. That's not their purpose. They are not building blocks. They are not checklist entries. They are exactly what the mundane meaning of patterns implies. They are things you see repeated over and over. Many times you sense their necessity ahead of time and so you include them in the design. But they are not a starting point.
Sometimes there just isn't any other way than doing the research. If you wish to learn design patterns then start studying design patterns. Learn a little each day, and as you do your normal coding you will begin to see uses for what you've learned. Personally, I like the way Wikipedia has tackled the topic (as opposed to some of the books). Read the overview, and then dive into the ones that you foresee as having some relevance to what you are trying to do.
Also, you may be interested in Enterprise Integration Patterns, as opposed to design patterns, which apply more to web services than to algorithms.